cybronix solutions

SOFTWARE DEVELOPMENT

Software development is the translation of a user need or marketing goal into asoftware product. Software development is sometimes understood to encompass the processes of software engineering combined with the research and goals of software marketing computer software products. This is in contrast to marketing software, which may or may not involve new product development .

STAKE HOLDER'S INTERVIEW

Stakeholder interviews are a common method used in requirement analysis. Some selection is usually necessary, cost being one factor in deciding whom to interview. These interviews may reveal requirements not previously envisaged as being within the scope of the project, and requirements may be contradictory.However, stakeholder shall have an idea of his expectation or shall have visualized his requirements

CONTACT STYLE REQUIREMENT LIST

One traditional way of documenting requirements has been contract style requirement lists. In a complex system such requirements lists can run to hundreds of pages.

MEASURABLE GOALS

Best practices take the composed list of requirements merely as clues and ask why, repeatedly, until the actual business purposes are discovered. Then stakeholders and developers can devise tests to measure what level of each goal has been achieved so far. These goals change more slowly than the long list of specific but unmeasured requirements. Once the small set of critical, measured goals has been established, rapid prototyping and short iterative development phases may proceed to deliver actual stakeholder value long before the project is half over.

PROTOTYPES

Users to visualize the application that isn't yet constructed. Prototypes help users get an idea of what the system will look like, and make it easier for users to make design decisions without waiting for the system to be built. Major improvements in communication between users and developers were often seen with the introduction of prototypes. Early views of the screens led to fewer changes later and hence reduced overall costs considerably.

However, over the next decade, while proving a useful technique, it did not solve the requirements problem:

• Managers once they see the prototype have a hard time understanding that the finished design will not be produced for some time.
• Designers often feel compelled to use the patched together prototype code in the real system, because they are afraid to 'waste time' starting again.
• Prototypes principally help with design decisions and user interface design. However, they can't tell you what the requirements were originally.
• Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.