Requirements Specification

Requirement Engineering

The process of software construction encompasses and includes answer to the following questions:

1. What is the problem to be solved? 
2. What are the characteristics of the entity that is used to solve the problem?
3. How will the entity be realized?
4.  How will the entity be constructed?
5. What approach will be used to uncover errors that were made in the design and construction of the entity?
6.  How will the entity be supported over the long term when users of the entity request corrections, adaptations, and enhancements?

 These questions force us to look at the software development process from different angles and require different tools and techniques to be adopted at different stages and phases of the software development life cycle

Software Requirements Definitions

IEEE defines software requirements as: 

 1. A condition or capability needed by user to solve a problem or achieve an objective. 

 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document. 

 3. A documented representation of a condition or capability as in 1 or 2. As can be seen, these definitions slightly differ from one another but essentially say the same thing: a software requirement is a document that describes all the services provided by the system along with the constraints under which it must operate

Role of requirements

Software requirements document plays the central role in the entire software development process. To start with, it is needed in the project planning and feasibility phase. In this phase, a good understanding of the requirements is needed to determine the time and resources required to build the software. As a result of this analysis, the scope of the system may be reduced before embarking upon the software development.

Levels of Software requirements

Software requirements are defined at various levels of detail and granularity. Requirements at different level of detail also mean to serve different purposes.

1.  Business Requirements -  These are used to state the high-level business objective of the organization or customer requesting the system or product. They are used to document main system features and functionalities without going into their nitty-gritty details. They are captured in a document describing the project vision and scope
2. User Requirements - They are written from a user's perspective and the focus of user requirement describe tasks the user must be able to accomplish in order to fulfill the above stated business requirements.
3.  Functional Requirements - They bring in the system's view and define from the system's perspective the software functionality the developers must build into the product to enable users to accomplish their tasks stated in the user requirements - thereby satisfying the business requirements.
4. Non - Functional Requirements -  These are used to describe external system interfaces, design and implementation constraints, quality and performance attributes.

What is Stakeholder?

Stakeholders are different people who would be interested in the software. A stakeholder can affect or be affected by its operations and performance. Stakeholders may include investors, employees, customers, suppliers, communities, governments, and trade associations. An entity's stakeholders may be internal or external to the organization.

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 
• 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.