Requirement Analysis
Alphasoft Systems Inc teams with client management, technical staff and users to accurately determine system requirements for all levels. Depending upon the project, we utilize prototyping methodologies, and/or process flow diagrams to accurately capture the requirements of the system. We have found that most of the problems with a system arise from a miscommunication of needs between the users and the designers. Prototyping and process flow diagrams are essential to allow users to visualize the complete system and easily articulate their requirements. As the saying goes, "A picture is worth 1000 words."
Our software development requirements' documents are comprehensive. They define input and output specifications along with the data model. Once completed, the requirements can be used to produce the completed software application. In addition, Alphasoft Systems Inc can be engaged to act as an independent advisor, working for the client's benefit, to develop the requirements for a project, write the RFP and evaluate the responses.
In software engineering, requirements analysis encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. Systematic requirements analysis is also known as requirements engineering. It is sometimes referred to loosely by names such as requirements gathering, requirements capture, or requirements specification. The term requirements analysis can also be applied specifically to the analysis proper (as opposed to elicitation or documentation of the requirements, for instance).
Requirements analysis is critical to the success of a development project
Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.
Requirements analysis can be a long and arduous process during which many delicate psychological skills are involved. New systems change the environment and relationships between people, so it is important to identify all the stakeholders, take into account all their needs and ensure they understand the implications of the new systems. Analysts can employ several techniques to elicit the requirements from the customer. Historically, this has included such things as holding interviews, or holding focus groups (more aptly named in this context as requirements workshops - see below) and creating requirements lists. More modern techniques include prototyping, and use cases. Where necessary, the analyst will employ a combination of these methods to establish the exact requirements of the stakeholders, so that a system that meets the business needs is produced.
Main Techniques
Stakeholder interviews
Stakeholder interviews are a common method used in requirement analysis.These interviews may reveal requirements not previously envisaged as being within the scope of the project, and requirements may be contradictory. However, each stakeholder will have an idea of their expectation or will have visualized their requirements
Contract-style requirement lists
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 repeatedly ask "why?" until the actual business purposes are discovered. Stakeholders and developers can then devise tests to measure what level of each goal has been achieved thus far. Such goals change more slowly than the long list of specific but unmeasured requirements. Once a 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
In the mid-1980s, prototyping was seen as the solution to the requirements analysis problem. Prototypes are mock-ups of an application. Mock-ups allow users to visualize an application that hasn't yet been 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 applications led to fewer changes later and hence reduced overall costs considerably.
However, over the next decade, while proving a useful technique, prototyping did not solve the requirements problem:
-
Managers, once they see a prototype, may have a hard time understanding that the finished design will not be produced for some time.
-
Designers often feel compelled to use 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 originally were.
-
Designers and end users can focus too much on user interface design and too little on producing a system that serves the business process.
-
Prototypes work well for user interfaces, screen layout and screen flow but are not so useful for batch or asynchronous processes which may involve complex database updates and/or calculations.
Prototypes can be flat diagrams (referred to as 'wireframes') or working applications using synthesized functionality. Wireframes are made in a variety of graphic design documents, and often remove all color from the software design (i.e. use a greyscale color palette) in instances where the final software is expected to have graphic design applied to it. This helps to prevent confusion over the final visual look and feel of the application.
Use cases
A use case is a technique for documenting the potential requirements of a new system or software change. Each use case provides one or more scenarios that convey how the system should interact with the end user or another system to achieve a specific business goal. Use cases typically avoid technical jargon, preferring instead the language of the end user or domain expert. Use cases are often co-authored by requirements engineers and stakeholders.
Software requirements specification
A software requirements specification (SRS) is a complete description of the behavior of the system to be developed. It includes a set of use cases that describe all of the interactions that the users will have with the software. Use cases are also known as functional requirements. In addition to use cases, the SRS also contains nonfunctional (or supplementary) requirements. Non-functional requirements are requirements which impose constraints on the design or implementation (such as performance requirements, quality standards, or design constraints).
Recommended approaches for the specification of software requirements are described by IEEE 830-1998. This standard describes possible structures, desirable contents, and qualities of a software requirements specification.
Stakeholder identification
A major new emphasis in the 1990s was a focus on the identification of stakeholders. It is increasingly recognized that stakeholders are not limited to the organization employing the analyst. Other stakeholders will include:
-
those organizations that integrate (or should integrate) horizontally with the organization the analyst is designing the system for
-
any back office systems or organizations
-
Senior management.
|