13 Requirements Engineering IV

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.

 

CHALLENGES IN REQUIREMENTS ELICITATION

 

Requirement elicitation engages in gathering and collecting of requirements from the stakeholders. Some of the challenges that are encountered during elicitation of requirements are three endemic syndromes that are as follows:

  • Yes-but syndrome: When the stakeholders are not sure about the specifications, or have vague idea about the system, they tend to provide hazy requirements and are inconsistent about their specification.
  • Undiscovered ruin syndrome: The search for requirements is like a search for undiscovered ruins, the more you find the more you know remain.
  • User and the developer syndrome: Communication gap between the user and the developer.

 

TYPES OF DATA

 

Data could be of two different types of classes:

  • Qualitative (descriptive information) and quantitative data (numerical information).
  • Structured (high degree of organization such as relational database) and unstructured data (Information that is difficult to organize using traditional mechanisms).

 

METHODS FOR COLLECTING DATA

 

Data collection involves elicitation and gathering of information from stakeholders and end users. Data collection is done by various methods such as:

  • Interview: Interviews are conducted with different level of stakeholders to solicit their views, suggestions and opinions on how the system has to be developed. The views and suggestion are collected from the stakeholders by conducting interviews, but it has its own pros and cons.

 

*  Pros

  • Rich collection of information
  • Uncovers opinions, feelings, goals, as well as hard facts.
  • Can review in detail, and adapt follow-up questions to what the person tells you.

 

*  Cons

  • Large amount of qualitative data can be hard to analyze
  • Not as many people from various parts of the company are interviewed, because of cost there exists high possibility for bias.
  • Usually many follow ups are required for clarification.
  • Interviewing is a difficult skill to master.
  • Questionnaires – Preparation of questionnaires and gathering honest response from the members leads to collection of data.
  • Background reading – Background study and comprehension of the system leads to collection of data
  • Introspection – The analyst “imagines” what kind of system is required for doing the required job, or by using available equipment collects data
  • Social analysis – collects data through observation.
  • Brainstorming – A group technique for generating new, productive ideas and promoting creative thinking for finding the solution to a specific issue
  • Story boarding – Story board is a logical and conceptual description of system functionality for a specific scenario, including the interaction required between the users and the system.
  • Prototyping – Data is collected with the help of prototypes.
  • Role playing – It allows the members to take up different roles to express their views and opinions.
  • Requirement  reuse  –  Requirements  are  reused  when  similar  types  of  systems  are developed.

 

METHODS FOR REQUIREMENT SPECIFICATION

 

Requirement specification is appropriate when description in language is too complex and when they can’t afford to have requirement misinterpretation. Some methods for requirement specification are as follows:

  • Pseudo code
  • Finite state machines
  • Decision tree
  • Object oriented modeling
  • Entity relationship models and many others.

 

Pseudo code

 

Pseudo code attempts to combine the informality of natural language with the strict syntax and control structures of a programming language. It comprises of imperative statements, a limited set of 40-50 “action oriented” verbs from which the sentences are constructed. The decisions are majorly represented with formal IF-ELSE-ENDIF structure. The iterative activities are represented with loops like DO, WHILE or FOR. Example for a pseudo code is given below:

 

Finite State Machine

 

Finite state machine can be in only one of a given number of “states” at any specific time. In response to an input, such as data entry from the user, or an input from an external device the machine changes its state and then generates an output or carries out an action. Both the output and the next state can be determined exclusively on the basis of understanding the current state and the event that caused transition. In that way the system’s behavior can be said to be deterministic.  The following example shows the finite states while driving a car.

Decision Trees

 

Decision trees are employed when dealing requirements with combination of inputs, different combination of input leads to different behaviors or outputs. The combination of IF- THEN-ELSE clauses becomes quickly twisted, when the conditions are nested.

 

Object Orient Modeling

 

If the requirements involve the description of the structure and relationship among entities within the system, it’s often beneficial to use object oriented models to fully describe the system. Examples for this modeling involve generation of class or sequential diagrams.

 

Entity relationship models

 

Entity relationship model (ER model) is a data model for describing a database in an abstract way. ER model provides a high level “architectural” view of the data. The given example provides the entity relationship model for an employee working in a department.

QUALITY MEASURES FOR WELL FORMED REQUIREMENTS

 

The quality of a well formed requirement is determined using the following measures:

  • Correctness – If every requirement stated represents something required of the system to build
  • Un-ambiguous – The requirements are subjected to only one interpretation as the requirements can be interpreted differently by the developers, users and other stakeholders. Requirements must be very clear and must be interpreted singularly.
  • Complete – All significant requirements of concern to the user, including requirements associated with the functionality, performance, design constraints, attributes or external interfaces.  It projects the functionalities and features that system should provide.
  • Consistent – No subset of individual requirements described within are in conflict with another requirements.
  • Verifiable – The requirements specified must be testable, therefore appropriate test procedures are carried out for verification.
  • Modifiable – Changes to the requirements can be made easily, completely and consistently, while retaining the existing structure and style of the set. It provides a provision for modification without changing the structure and style of the system.
  • Traceable – Origin of each of its component requirements must be clear to trace back if there is any shortcomings in the system. The system should try to provide mechanism that makes it feasible to refer to the requirement that causes inadequacy in the development of the system.
  • Understandable – The user and the developer community must be able to fully understand the individual requirements and the aggregate functionality implied by the set.

 

REQUIREMENTS VALIDATION – TRACEABILITY

 

IEEE in 1994 provided the following compound definition of traceability:

  • Ability to describe and follow the life of a requirement, in both forward and backward direction.
  • Traceability importance increases where the rate of change is high.
  • Some requirements are volatile.

 

Classification of Requirement Traceability

 

Requirement traceability can be classified into two types: Forward traceability and backward traceability.

  • Forward traceability – Each input of the phase must be traced to the output of that phase.
  • Backward traceability – Each output of a phase must be traceable to an input of that phase.

 

Outputs that cannot be traced to inputs are extra, unless it is acknowledged that input themselves were incomplete.

 

An example of the traceability matrix is given as follows, where the list of features and their needs are depicted in a matrix of n * m. The stakeholder’s needs and product features are depicted and with help of product features, one can trace back the needs of the stakeholders. The matrix features and use cases are also given, where the product feature can be traced from the use cases.

 

Traceability matrix for tracing product features

REQUIREMENT REVIEWS

 

Requirement review involves a group of people to conduct requirement analysis, determine the problems and issues encountered, conduct discussion about the problem and agree on the actions to address these problems. It is a formal meeting headed by a leader. Reviews are conducted not only to uncover errors but also to check conformance of standards.

 

Requirement Review Process

 

A requirement review process goes through the following phases as shown in the below figure.

The members plan the review to be conducted and distribute documents that contains the goals and agenda of the review. The members prepare for the review and the review meeting is conducted. The members express their views and suggestions to uncover errors and faults in the specification and development cycle. After uncovering and prioritizing the errors and shortcomings, necessary follow up actions are discussed to overcome the inadequacies in the system. The review session is documented and the specification documents are revised. The process bridges the gap between the stakeholders and the developers and improves the standard and efficiency of the system.

 

 

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
  • http://resources .sei.cmu.edu/asset_files/TechnicalReport/2005_005_001_14594.pdf

 

Supporting & Reference Materials

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