Requirements engineering
1 / 40


  • Uploaded on

REQUIREMENTS ENGINEERING. What is a requirement?. Descriptions of the services provided by the system and its operational constraints. Reflects the needs of customers for a system. May be… A high level, abstract statement of a service that the system should provide A constraint on the system

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'REQUIREMENTS ENGINEERING' - umeko

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Requirements engineering


What is a requirement
What is a requirement?

  • Descriptions of the services provided by the system and its operational constraints.

  • Reflects the needs of customers for a system.

  • May be…

    • A high level, abstract statement of a service that the system should provide

    • A constraint on the system

    • A detailed formal definiton of a system function.

Requirements engineering1
Requirements engineering

  • The process of finding out, analysing, documenting and checking these services and constraints.

Types of requirements
Types of requirements

  • User requirements:

    • high-level abstract requirements

    • Statements of what services the system is expected to provide and the constraints under which it must operate.

  • System requirements:

    • The detailed description of what the system should do

    • Set out the system’s func., services and operational constraints in detail.

Types of requirements cont
Types of requirements cont.

  • User requirements may be expanded into several system requirements by adding detail, explaining the services and functions.

  • Requirements should be written at different levels of detail because of different readers.

Functional and nonfunctional requirements
Functional and nonfunctional requirements

  • Functional requirements

    • Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situations.

  • Non-functional requirements

    • constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.

  • Domain requirements

    • Requirements that come from the application domain of the system and that reflect characteristics of that domain.

Functional requirements
Functional requirements

  • Describe the system function in detail, its input and outputs, exceptions etc.

  • Depends on…

    • The type of software

    • The expected users of the software

  • The specification of the functional requirements should be complete and consistent.

Nonfunctional requirements
Nonfunctional requirements

  • May relate to reliability, response time and store occupancy.

  • Constraints are I/O device capability, system representations, etc.

  • May specify performance security and availability. So more critical than individual functional requirements.

  • Failing to meet can mean the whole system is unusable.

Types of nonfunctional requirements
Types of nonfunctional requirements

  • Product req. Specify product behavior

    • Performance, reliability, portability, usability

  • Organisational req.

    • Process standards, implementation, delivery

  • External req.

    • Interoperability, legislative, ethical


  • Functional requirement:

    • “The customer must place an order within two minutes of registering.”

  • Nonfunctional requirement:

    • “The customer must be able to access their account 24 hours a day, seven days a week.”

Domain requirements
Domain requirements

  • Derived from the application domain and describe system characteristics and features that reflect the domain.

  • Domain requirements maybe new functional requirements, constraints on existing requirements or define specific computations.

  • If domain requirements are not satisfied, the system may be unworkable.

Domain requirements example
Domain requirementsexample

  • Tolerance level of landing gear on an aircraft (different on dirt, asphalt, water), or what happens to fiber optics line in case of sever weather during winter Olympics (Only domain-area experts know)

Domain requirements problems
Domain requirements problems

  • Understandability

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

User requirements
User requirements

  • Should describe the functional and nonfunctional requirements.

  • Should only specify the external behavior of the system.

  • System design characteristics, software jargon, structuredor formal notations, system implementation should be excluded.

  • Should be written in simple language.

Guidelines for writing requirements
Guidelines for writing requirements

  • Invent a standard format and use it for all requirements.

  • Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements.

  • Use text highlighting to identify key parts of the requirement.

  • Avoid the use of computer jargon.

System requirements
System requirements

  • Expanded version of user req.

  • Describe the external behavior of the system and its operational constraints.

  • Must not include how the system designed and implemented.

Problems with nl specification
Problems with NL specification

  • Ambiguity

    • The readers and writers of the requirement must interpret the same words in the same way. NL is naturally ambiguous so this is very difficult.

  • Over-flexibility

    • The same thing may be said in a number of different ways in the specification.

  • Lack of modularisation

    • NL structures are inadequate to structure system requirements.

Structured language specifications
Structured language specifications

  • Limits the terminology that can be used and use templates to specify system req. System req. May be specified by:

    • Using forms

    • Using tables

    • Using graphical models

Form based specifications
Form-based specifications

  • Definition of the function or entity.

  • Description of inputs and where they come from.

  • Description of outputs and where they go to.

  • Indication of other entities required.

  • Pre and post conditions (if appropriate).

  • The side effects (if any) of the function.

Form based specification example
Form based specification example


Function:Add node

Description:Adds a node to an existing design.

Inputs: Node type, Node Position

Outputs:Design identifier

Pre/Post conditions:

Other attributes:

Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1

Structured lang specification cont
Structured lang. specification cont.

  • By using formatted specification variability is reduced and req. are organised more efficiently.

  • When complex requirements are needed tables or graphical models can be used.

    • Use tables when there are a number of possible alternative situations.

    • Use graphical models when you need to show how state changes or describe a sequence of actions.

The requirements document
The requirements document

  • SRS (software requirement specification) is the official statement of what the system developers should implement

  • Includes both user requirements and detailed specification of the system requirements.

The requirements document cont
The requirements document cont.

  • Has a diverse set of users

    • the req. document has to be a compromise between communicating the requirement to customers, defining them in precise detail for developers and testers and including information about possible system evolution.

  • The level of detail depends on the type of system that is being developed and the development process used.

    • External contractor: very detailed

    • Iterative development process: less detailed

Ieee requirements standard
IEEE requirements standard

  • Defines a generic structure for a requirements document that must be instantiated for each specific system.

    • Introduction.

    • General description.

    • Specific requirements.

    • Appendices.

    • Index.

Feasibility studies
Feasibility studies

  • A feasibility study decides whether or not the proposed system is worthwhile.

  • Inputs: List of business requirements, system description, how the system improve business

  • Outputs: Answer of the question “Should we do this development?”

Elicitation and analysis
Elicitation and analysis

  • Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints.

  • STAKEHOLDER: End-users, managers, engineers involved in maintenance, domain experts, trade unions, etc.

  • Shortly; people affected by the system directly or indirectly.

Requirements discovery
Requirements discovery

  • The process of gathering information about the proposed and existing systems and distilling the user and system requirements from this information.

  • This information comes from documentation, system stakeholders and the specifications of similar systems.

Registration boun edu tr

  • Who are stakeholders?


  • In formal or informal interviewing, the Requirements Engineering team puts questions to stakeholders about the system that they use and the system to be developed.

  • There are two types of interview

    • Closed interviews where a pre-defined set of questions are answered.

    • Open interviews where there is no pre-defined agenda and a range of issues are explored with stakeholders.


  • Scenarios are real-life examples of how a system can be used.

  • They should include

    • A description of the starting situation;

    • A description of the normal flow of events;

    • A description of what can go wrong;

    • Information about other concurrent activities;

    • A description of the state when the scenario finishes.

Use cases
Use cases

  • Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself.

  • A set of use cases should describe all possible interactions with the system.

  • Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

Registration use cases

Add course

Drop course


Consent Requests


Course scheduling



Registration use cases

Add cmpe 352


Regs system






Cmpe 352

Ayse Basar Bener






Add OK

Inform available

Add available





Add CMPE 352


  • A social scientists spends a considerable time observing and analysing how people actually work.

  • Social and organisational factors of importance may be observed.

  • Ethnographic studies have shown that work is usually richer and more complex than suggested by simple system models.

  • Requirements that are derived from the way that people actually work rather than the way which process definitions suggest that they ought to work. Reality!!!

  • Requirements that are derived from cooperation and awareness of other people’s activities.

Requirements validation
Requirements validation

  • Concerned to validate that the requirements define the system that the customer really wants.

  • Requirements error costs are high so validation is very important

    • Fixing a requirement error before completing project or delivering it is much more cheaper...

Requirements checking
Requirements checking

  • Validity. Does the system provide the functions which best support the customer’s needs?

  • Consistency. Are there any requirements conflicts?

  • Completeness. Are all functions required by the customer included?

  • Realism. Can the requirements be implemented given available budget and technology

  • Verifiability. Can the requirements be checked?

Requirements management
Requirements management

  • Requirements management is the process of managing changing requirements during the requirements engineering process and system development.

  • Requirements are inevitably incomplete and inconsistent

    • There will be always requirements during the process as business needs change and a better understanding of the system is developed;

    • Different viewpoints have different requirements and these are often contradictory; Students do not want to take courses starting at 09.00am, Instructors do not want to come to school everyday.

Requirements change management
Requirements change management

  • Should apply to all proposed changes to the requirements.

  • Principal stages

    • Problem analysis. Discuss requirements problem and propose change;

    • Change analysis and costing. Assess effects of change on other requirements;

    • Change implementation. Modify requirements document and other documents to reflect change.


  • Ian Sommerville, Software Engineering



  • Deriving Tabular Event-Based Specifications

    from Goal-Oriented Requirements Models - Renaud De Landtsheer, Emmanuel Letier and Axel van Lamsweerde

  • Bahill A.T. And Dean F.F., Handbook of Systems Engineering and Management