As mentioned earlier, in order to develop a good requirement document, it is imperative to involve all kinds of user in the requirement engineering process. The first step in fulfillment of this need is the identification of all the stakeholders in the system. Stakeholders are different people who would be interested in the software. It is important to recognize that management carries a lot of weight, but they usually are not the actual users of the system. We need to understand that it is the actual user who will eventually use the system and hence accept or reject the product. Therefore, ignoring the needs of any user class may result in the system failure.

A requirement engineer should be cognizant of the fact that stakeholders have a tendency to state requirements in very general and vague terms. Sometimes they trivialize things. Different stakeholders have different requirements – sometimes even conflicting. On top of that internal politics may influence requirements.

The role of stakeholders cannot be overemphasized. A study of over 8300 projects revealed that the top two reasons for any project failure are lack of user input and incomplete requirements.

The following diagram shows the role of different stakeholders in the setting the system requirements.

Requirement Statement and Requirement Specification Documents

Different levels of software requirements are documented in different documents. The two main documents produced during this phase are Requirement Statement and Requirement Specification. They are also called Requirement Definition and Functional Specification and are used to document user requirements and functional requirements respectively.

Requirement Statement Characteristics

A good Requirements statement document must possess the following characteristics.

• Complete – Each requirement must fully describe the functionality to be delivered.
• Correct – Each requirement must accurately describe the functionality to be built.
• Feasible – It must be possible to implement each requirement within the known capabilities and limitations of the system and its environment.

Necessary –Each requirement should document something that the customer really need or something that is required for conformance to an external system requirement or standard.

• Prioritized – An implementation priority must be assigned to each requirement, feature or use case to indicate how essential it is to a particular product release.
• Unambiguous – All readers of a requirement statement should arrive at a single, consistent interpretation of it.
• Verifiable – User should be able to devise a small number of tests or use other verification approaches, such as inspection or demonstration, to determine whether the requirement was properly implemented.

Requirement Specification Characteristics

A         good    Requirements    specification    document    should    possess    the    following characteristics.

• Complete – No requirement or necessary information should be missing.
• Consistent – No requirement should conflict with other software or higher-level system or business requirements. Following is another set of (functional) requirements that conflicted with one another:
• System must monitor all temperatures in a chemical reactor.
• System should only monitor and log temperatures below -200 C and above 4000 C. In this case the two requirements clearly conflict with each other in stating what information needs to be monitored and stored.
• Modifiable – One must be able to revise the Software Requirement Specification when necessary and maintain a history of changes made to each requirement.
• Traceable – One should be able to link each requirement to its origin and to the design elements, source code, and test cases that implement and verify the correct implementation of the requirement.

Requirements interaction

• Conflicts between different non-functional requirements are common in complex systems.
• Spacecraft system
  • To minimise weight, the number of separate chips in the system should be minimised.
  • To minimise power consumption, lower power chips should be used.
  • However, using low power chips may mean that more chips have to be used. Which is the most critical requirement?

Domain requirements

• Derived from the application domain and describe system characteristics and features that reflect the domain.
• Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.
• If domain requirements are not satisfied, the system may be unworkable.

Domain requirements problems

• Understand-ability
  • Requirements are expressed in the language of the application domain;
  • This is often not understood by software engineers developing the system.
• Implicitness
  • Domain specialists understand the area so well that they do not think of making the domain requirements explicit.