CH 4

CS 410/510 - Software Engineering
Requirements Engineering
Reference: Sommerville, Software Engineering, 10 ed., Chapter 4
The big picture

Requirements engineering (RE) is the process of establishing the services that the customer requires
from a system and the constraints under which it operates and is developed. The requirements themselves
are the descriptions of the system services and constraints that are generated during the requirements
engineering process. Requirements may range from a high-level abstract statement of a service or of a
system constraint to a detailed mathematical functional specification. As much as possible, requirements
should describe what the system should do, but not how it should do it.
Two kinds of requirements based on the intended purpose and target audience:
User requirements
High-level abstract requirements written as statements, in a natural language plus diagrams, of what
services the system is expected to provide to system users and the constraints under which it must
operate.
System requirements
Detailed description of what the system should do including the software system's functions, services,
and operational constraints. The system requirements document (sometimes called a functional
specification) should define exactly what is to be implemented. It may be part of the contract between
the system buyer and the software developers.
Three classes of 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. May state what the system should not do.
Non-functional requirements
Constraints on the services or functions offered by the system such as timing constraints, constraints
on the development process, standards, etc. Often apply to the system as a whole rather than
individual features or services.
Domain requirements
Constraints on the system derived from the domain of operation.
Functional requirements
Functional requirements describe functionality or system services. They depend on the type of software,
expected users and the type of system where the software is used.
• Functional user requirements may be high-level statements of what the system should do.
• Functional system requirements should describe the system services in detail.
Problems arise when requirements are not precisely stated. Ambiguous requirements may be interpreted in
different ways by developers and users. In principle, requirements should be both
• Complete: they should include descriptions of all facilities required, and
• Consistent: there should be no conflicts or contradictions in the descriptions of the system facilities.
In practice, it is impossible to produce a complete and consistent requirements document.
Non-functional requirements
Non-functional requirements define system properties and constraints e.g. reliability, response time and
storage requirements. Constraints are 1/0 device capability, system representations, etc. Process
requirements may also be specified mandating a particular IDE, programming language or development
method. Non-functional requirements may be more critical than functional requirements. If these are not
met, the system may be useless.
Non-functional requirements may affect the overall architecture of a system rather than the individual
components. A single non-functional requirement, such as a security requirement, may generate a number of
related functional requirements that define system services that are required. It may also generate
requirements that restrict existing requirements.
• Verifiability: can the requirements be checked?
Requirements validation techniques:

Requirements reviews
Systematic manual analysis of the requirements. Regular reviews should be held while the
requirements definition is being formulated. What to look for:
• Verifiability: is the requirement realistically testable?
• Comprehensibility: is the requirement properly understood?
• Traceability: is the origin of the requirement clearly stated?
• Adaptability: can the requirement be changed without a large impact on other requirements?
Prototyping
Using an executable model of the system to check requirements.
Test-case generation
Developing tests for requirements to check testability.
Requirements change
Requirements management is the process of managing changing requirements during the requirements
engineering process and system development. New requirements emerge as a system is being developed
and after it has gone into use. Reasons why requirements change after the system's deployment:
• The business and technical environment of the system always changes after installation.
• The people who pay for a system and the users of that system are rarely the same people.
• Large systems usually have a diverse user community, with many users having different requirements
and priorities that may be conflicting or contradictory.

CH 4

Uploaded by

Copyright:

Available Formats

CH 4

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH 4

Uploaded by

Copyright:

Available Formats

CS 410/510 - Software Engineering

Reference: Sommerville, Software Engineering, 10 ed., Chapter 4

The big picture

In practice, it is impossible to produce a complete and consistent requirements document.

Requirements validation techniques:

You might also like

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.