Requirement Engineering

by

Dr. Rizwan

Requirement

The hardest single part of building a software system is deciding what to build….

No other part of the work so cripples the resulting system if done wrong.

No other part is more difficult to rectify later.

F.P Brooks

Requirement Software Requirement stimulates what must be

Accomplished, Transformed, Produced or Provided

Additionally, a Software Requirement is a software capability that must be met or possessed by a software component in order to satisfy a contract, standard, or specification

The source of these Requirements could come from Client/Customer Buyers, Users/End user, or system specifications

Requirement Engineering

The description of the services and constraints are the requirements for the system and

The process of Finding out, Analyzing, Documenting and Checking these services and Constraints are called

Requirements Engineering.”

Ian Sommerville

Requirement Engineering

A process in which “what is to be done” is

Elicited Modeled and Communicated Freeman

Why are requirements important? The requirements are how we communicate They are the only part that everyone understand

CUSTOMER

USER DEVELOPER

Requirements

How are Programs Usually Written …

The requirements specification was defined like this

The developers understood it in

that way

This is how the problem is solved now

That is the program after debugging

This is how the program is described by marketing

department This, in fact, is what the customer wanted … ;-)

Why are requirements important? Inconsistent and incomplete requirements are the

most frequent causes of the system problems

10% 20%

Incomplete requirements

Lack of user involvement

Lack of resources

Unrealistic expectations

Lack of executive support

Changing requirements

Lack of planning

System no more needed

Causes of the failed projects

Requirement Types

Needs The capabilities and characteristics required in

the software system to solve the problem.

Wishes/Wants The capabilities and characteristics of the

software system desired by the users.

Expectations The capabilities and characteristics of the

software system expected by the users.

Software Requirement Specification Document

SRS (Software Requirement specification) The official statement of what is required by the

system developers The goal of the SRS is to describe all externally

observed behaviors and characteristics expected of the software system

Includes user requirements and system requirements Standards for SRS

RUP IEEE Ian Summerville

Characteristics of SRS

Correct All requirements stated in the SRS are one that the

software shall meet.

Unambiguous Every requirement stated in the SRS only has one

logical interpretation.

Complete The SRS includes all significant requirements The SRS includes all realizable classes of input data The SRS includes full labels and references to all

figures, tables and diagrams.

Characteristics of SRS

Verifiable For every requirement stated in the SRS, there exists

some finite cost-effective process with which a person or machine can check that the software meets the requirements.

Modifiable The entire SRS has a style and structure such that

any changes to the requirements can be made Easily, Completely, and Consistently and retaining the structure and style.

Characteristics of SRS

Consistent No subset of individual requirements stated in the SRS

conflict with other individual requirements.

Traceable For every requirement stated in the SRS, it is clear of

the requirements origin and it is possible to reference each requirement in future developments.

Advantages of SRS

The SRS can establish the basis for contractual agreement between the customer and developers.

The SRS can establish the basis for performing cost, schedule, and resource estimates for the developmental effort.

The SRS can provide a baseline for verification and validation of the software.

Types of SRS

Production of System Specification Written document Graphical model Formal mathematical model Usage scenarios Prototype Any combination of above

IEEE Standard

Introduction Purpose of the requirement document Scope of the product

Definitions, acronyms, and abbreviations

References

Why Engineer Requirement

Wicked problems Most large software systems address wicked

problems Problems which are so complex that they can never

be fully understood and where understanding evolves during the system development

Therefore, requirements are normally both incomplete and inconsistent

Requirement Types

Functional Requirements The functional requirements define the fundamental actions

that the software must perform. The actions describes accepting inputs, processing, and

generating the outputs.

Behavioral Requirements The behavioral requirements define the actions taken when

the software responds to internal and external stimulus. This includes describing what event causes an activity to

start up and the event that causes it to stop.

Requirement Types

Performance Requirements The performance requirements specify the numeric

requirements that are placed of the software as well as on the human interaction with the software.

Examples of performance requirements may include: Number of data transactions with in a certain time frame Number of simultaneous users Number of terminals to be supported

Requirement Types

Operational Requirements Are usability of the software as it communicates with its

human users. This may include information concerning the

Qualifications of the users, Level of detail for external messages, and Graphical User Interface standards.

The constraint requirements Define any restrictions that will impact the software that is

being developed.

Requirement Types

The constraint requirements Constraint requirements deal with:

Design/Development restrictions. Example: Target hardware and programming

language. Environment Restrictions.

Example: Software size and resource utilization. Data Restrictions.

Example: Maximum number of files and size of files.

Requirement Engineering Process

Requirement Engineering All activities devoted to

Identification of user requirements, Analysis of the requirements to drive additional

requirements, Documentation of the requirements as a specification Validation of the documented requirements against

user needs, as well as processes that support these activities.

Requirement Engineering Process

Software Requirement Elicitation The process through which the customers, buyers

or the users of software system discover, reveal, articulate and understanding their requirements

Software Requirements Elicitation is any activity that has as its objectives to:

Gather, Determine, Extract, or expose software requirements

Requirement Engineering Process

Software Requirement Analysis The process of reasoning about the requirements that

have been elicited . Involves examining requirements for conflicts or

inconsistencies, combining related requirements, and identifying missing requirements

Software Requirements Analysis is any activity that has as its objective to

Organize, Interpret, Understand, Classify, or assess feasibility, Completeness, or consistency of software requirements.

Requirement Engineering Process

Software Requirement Specification The process of recording the requirements in one or more

forms, including natural language and formal, symbolic, or graphical representations

Software Requirements Specification is any activity that has as its objective to capture a description of the software requirements

Usually the final form of this description is a software requirements specification (SRS).

Software Requirement Validation The process of confirming with the customer or user of the

software that the specified requirements are valid, correct, and complete

Software Requirements Validation is any activity that has as its objective to obtain buyer approval of the specification of the software requirements.

Requirement Engineering Process

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

Requirement Engineering Process

In reality these processes cannot be performed sequentially

All process are intertwined and performed repeatedly Elicitation is not universally accepted

Identifying

Gathering

Determining

Formulating

Extracting

Exposing

Outcomes of Requirement Elicitation

TangibleIntangible

Outcome of a Good Elicitation Process

Users Perspective The users will have a better understanding of their needs and

constraints. The users will be in a position to evaluate alternatives and

understand the implications of their decisions. This level of understanding is extremely important since it is

usually the users who drives the requirements, which in turn drives the design and implementation of the entire software system.

Thus, the quality of the requirements document is related to the users understanding of the issues and tradeoffs involved.

Outcome of a Good Elicitation Process

Users Perspective The users and the developers form a common vision of

the problem and the conceptualized software solution. To strive for this common understanding of all

individuals involved in the software engineering process

A sense of ownership Feel informed and educated Committed to the success of the project

Outcome of a Good Elicitation Process

Developers Perspective This is the fundamental process that will be used

to construct a clear high level specification of the problem that is to be solved.

Other outcomes of a good elicitation process are developers who:

Are developing a solution to the right problem Are solving a problem that is feasible from all

perspectives Have a high level specification of the solution Have cooperative users

Outcome of a Good Elicitation Process

Developers Perspective Have all the necessary information, explanations, and

justifications Can make proper design justifications Need minimal ongoing interactions with the users They have trust and confidence of the customer Knowledge of the domain of the system

Difficulties in Requirement Elicitation

The process of elicitation of requirements is a difficult process. No single person has the complete picture. Work effectively as a coherent group. The following are some common difficulties associated with this

process:

Articulation Problems Expression/ Communication Articulation problems can occur because the users are usually

experts in their application domain but not in the process of engineering software.

Additionally, the engineers are experts in development and not in the users application domain.

This problem is magnified by the users and developers having different vocabulary, terms, and concepts

Difficulties in Requirement Elicitation

Articulation of the users needs The users may not be aware of their needs Users who are unwilling to prioritize and make tradeoffs The users may be aware of needs but be afraid to articulating it Users and developers misunderstand concepts or relationships User cannot make up their minds No single person has complete picture Developers may not really be listening to the users

Difficulties in Requirement Elicitation

Articulation of the users needs Developer may fail to understand, appreciate, or relate to the

users Developers who are not skilled in listening Developers who are dominating in their approach to

elicitation Developers who are solution not problem orientated

Difficulties in Requirement Elicitation

Communication Barriers Communication is not a single direction information flow Users and developers come from different worlds and have

different professional vocabularies The users have different concerns from those of developers Medium of communication-Natural language are inherently

ambiguous People involved are different-some are submissive, some

are assertive

There are different value system among people

Difficulties in Requirement Elicitation

Problem Complexity The complexity of modern software system makes the

process of requirements elicitation extremely difficult. These systems have interconnections between subsystems

and environments that even expert in specialized disciplines have difficulty understanding.

Nature of Requirements Requirements change and migrate Users learn and grow Requirements are diverse and conflicting Multiple views can be difficult to integrate Requirements can be difficult to evaluate.

Difficulties in Requirement Elicitation

Knowledge and Cognitive Limitations Tunnel vision User and Developers don’t have adequate domain

knowledge No person has perfect memory Interpretation of statistics Problem simplification and ignoring part of the problem

because of complexity Some people are uncomfortable or impatient with

exploration

Human Behavioral Issues Elicitation is a social process Everyone (users) assumes that it is not his/her responsibility to

tell the developers Developer may assume that user will give the information

User may assume that developer will ask appropriate questions

Expectation and /or fears from proposed system

Technical Issues Obsolete requirement by the time the elicitation process is

completed Software and hardware technologies (corporate management,

government regulations, sales and marketing department)

Unprecedented system

Difficulties in Requirement Elicitation

Requirement Elicitation Techniques

Joint Application Development (JAD) Quality Function Deployment (QFD) Adaptive Loops Framework Prototyping Contextual Inquiry Critical Success Factors Analysis Brainstorming Interviewing PIECES framework

Performance information and data, Economy

Control, Efficiency, and services

Key Points

Requirements set out what the system should do and define constraints on its operation and implementation.

Functional requirements set out services the system should provide.

Non-functional requirements constrain the system being developed or the development process.

User requirements are high-level statements of what the system should do. User requirements should be written using natural language, tables and diagrams.

System requirements are intended to communicate the functions that the system should provide.

It is very difficult to formulate a complete and consistent requirements specification

Volatile requirements are dependent on the context of use of the system

Key Points

A software requirements document is an agreed statement of the system requirements.

The IEEE standard is a useful starting point for defining more detailed specific requirements standards.

A requirements definition, a requirements specification and a software specification are ways of specifying software for different types of reader

The requirements document is a description for customers and developers

Requirements errors are usually very expensive to correct after system delivery

Reviews involving client and contractor staff are used to validate the system requirements