12 Requirement Engineering III

R. Baskaran

REQUIREMENTS ENGINEERING

Requirement engineering plays a vital role towards the development of the system. It involves gathering requirements from the end-users and stakeholders and documentation of these requirements to facilitate the development of the system. The learning objective includes:

To give a general introduction of requirements engineering process
To describe the principal requirements engineering activities and their relationships.
To introduce the concepts of user and system requirements.
To describe functional and non functional requirements.

SOFTWARE REQUIREMENT

Software requirement is a description of the system that has to be developed. The customer gets an understanding of what is to be developed, which is translated to the developer in their native language. The developer gathers all the information and requirements from the customers and stakeholders, analyzes the requirements and proceeds with the development of the system.

Software requirement is complete description of what the software system will do without describing how it will do it. Software requirements may be:

Abstract statements of services – e.g. Develop a library management system, here the in depth details or complexity of the system is not provided.
Part of the bid of the contract – e.g. Discussion on LOC, blueprint of the system, resource allocation etc
The contract itself.
Part of the technical document which describes a product. Software requirements are gathered from various sources such as:
Stakeholders
Documents
Existing System
Application domain

IMPORTANCE OF SOFTWARE REQUIREMENTS

The 2014 Standish Group survey studied the three most commonly cited factors that caused the projects to be “challenged”. The survey clearly projects the importance of software requirements and the factors that caused challenges in the development of the system. The major factors that caused hindrance in the project were due to lack of user input, incomplete requirements and specification, changing requirements and specification. The survey depicted that 13% of projects failed due to the lack of user input, 12% of the project failed due to incomplete requirement and specification and 12 % of the failed due to changing requirements and specification.

The data diverges very rapidly which leads to the setbacks or failure of project many times. The failure of projects can occur because of the following reasons:

Unrealistic scheduling or time frame (4% of the project stated this)
Inadequate staffing and resources (6 %)
Inadequate technology skills (7%)
Various other reasons

The survey shows that at least one third of the development projects run into trouble for reasons that are directly related to requirements gathering, requirements documentation and requirements management.

FREQUENCY OF THE REQUIREMENT ERROR

After gathering all these specific details, the developers do a thorough understanding of the requirements to get a clear picture of what is to be developed, then proceeds with design and implementation of the system. During this phase of requirement elicitation and comprehension, estimation of the frequency of requirement errors is computed. The frequency error estimation projects the defect origin, the defect potential, removal efficiency of the defects and the quantization of the delivered defects. The frequency error estimation through a development cycle is as follows:

Requirement error tops delivered defects and contribute approximately one third of the total delivered defects to the defect pile.

HIGH COST OF REQUIREMENT ERRORS

Rectification of errors at early phases of development cycle saves a lot of cost and resources. Defects are discovered at various phases such as,

Requirement analysis phase – 74 % of the requirement-oriented defects.
High-level design – 4% of the requirements defects “leak” and that 7% leak further into detailed design.
The leakage continues throughout the lifecycle and a 4% of the requirement errors aren’t found until maintenance, when the system is released to the customers and are likely in full scale operation.

Requirement errors lead to many possible activities such as:

Re-specification of requirement gathering or documentation
Re-design
Re-coding
Re-testing
Change orders
Scrap
Warranty costs
Product liability and service cost
Documentation

TYPES OF SOFTWARE REQUIREMENTS

The two major software requirements are: functional and non functional requirement.

Functional requirement

Functional requirements are described as the set of inputs, the behavior and outputs. It illustrates about the type of input that can be feed into the system, the response or behavior of the system to the given input and the output. Functional requirements also comprises of calculations, technical details, data manipulation, data processing and other specific functionalities that provides the definition of what the system is supposed to accomplish. Functional requirements should be complete and consistent. Customers and developers usually focus all their attention on non functional requirements.

Non functional requirements

Non functional requirements encompass requirements that are based on the quality of the system. Non functional requirements majorly consist of three categories: Product requirements, process requirements, and external requirements.

Product requirement focuses on the features and what the product does. It focuses mainly on the usability, portability, efficiency, reliability, performance and space. Process requirements focus on the deliverable and the standards achieved by the system. It focuses on the flow adopted, the methodologies and approaches adopted to develop an efficient system. External requirements focus on interoperability requirements, ethical requirements, legislative requirements (Privacy and safety requirements).

TEAM FOR EFFECTIVE REQUIREMENT MANAGEMENT

The requirement engineer should posses the following skills to promote an effective requirement management team.

Should possess an in depth analysis of the problem.
Should understand the needs of the customers, end-users and stakeholders.
Should provide a clear definition of the system
Scope management
Refinement of system of definition
Building the right system

Tasks of a requirement engineer comprises of the following activities:

Define business needs
Identification of project stakeholders and user classes.
Elicit requirements
Analyze requirements
Write specifications
Model the requirements
Lead validation
Facilitate prioritization
Manage requirements

REQUIREMENT ENGINEERING PROCESS

Requirement engineering is done at two levels: Requirements development and requirement management.

Requirement Development

Requirement development requires the active participation of the stakeholders and the process comprises of the following phases:

Requirement elicitation – The developers work closely with the customers and stakeholders to gather the requirements needed for the development of the system.
Requirement analysis and elaboration – The requirement engineers process the information gathered from the stakeholders, process the information for through understanding, classify them in various categories, and relate the customer needs to possible requirements.
Requirement specification – The requirement engineers structure the customer input and derived documents as written documents and diagrams.
Requirement validation – Customers validate, verify and confirm the accuracy and completeness of the requirements specified by the requirement engineer. The customers also correct the requirements in case of errors or faults.

Requirements Management

Requirement management involves changes and communication with stakeholders about the requirements of the system. It comprises of traceability, change management and fulfillment. Traceability focuses on tracking where the requirements are met and the failure to meet any requirement that has been specified by the customer. Change management focuses on requirement maintenance and propagation. Fulfillment deals with the results and confirmation of successful requirements.

Web Links

https://en.wikipedia.org/wiki/Requirements_engineering
http://www.tutorialspoint.com/software_engineering/software_requirements.htm
http://www.cs.toronto.edu/~sme/papers/2004/FoRE-chapter01-v7.pdf

Supporting & Reference Materials

Roger S. Pressman, “Software Engineering: A Practitioner’s Approach”, Fifth Edition, McGraw Hill, 2001.
PankajJalote, “An Integrated Approach to Software Engineering”, Second Edition, Springer Verlag, 1997.
Ian Sommerville, “Software Engineering”, Sixth Edition, Addison Wesley, 2000.