Requirements Engineering Fundamentals

SWENG 580: advanced software engineering
Requirements Engineering
fundamentals
What is requirements engineering ?

What are requirements?
How are requirements specified?
© Engineering Division, The Pennsylvania State University SWENG 580: Advanced Software Engineering
What is requirements engineering?

• Requirements engineering is the branch of software engineering concerned
with the real-world goals for, functions of, and constraints on software
systems. It is also concerned with the relationship of these factors to
precise specifications of software behavior, and to their evolution over time
and across software families.” (Zave, 1997)
2
“real world goals”

• Motivation for development of the software system
– Why are we building the system?
– What system are we building?
3
“precise specification”
• Provide the basis for
– Analyzing the requirements
– Validating that these requirements are what stakeholders want
– Defining what the designers have to build
– Verifying that the designers have built the right system
4
SWENG 580: Advanced Software Engineering
“evolution over time and across software

© Engineering Division, The Pennsylvania State University
families”
• Emphasizes the reality of
– A changing world
– The need to reuse partial specifications
5
Core RE activities
• Planning and Eliciting requirements.

– Who is the target for elicitation?
– What techniques are used for elicitation?
– Are requirements feasible?
– How to identify and manage risk?
• Modeling and Analyzing requirements.
– How formal and abstract should be the model?
– How expressive is the model? Does it support multiple different viewpoints?
– What are the techniques for modeling enterprises, information structures, and behavior?
– How do you model quality requirements?
• Communicating and Agreeing requirements.
– How are requirements documented?
– How do you negotiate and prioritize requirements?
– How do you review and inspect requirements?
– How do you validate requirements?
• Realizing and Evolving requirements
– How do you manage change?
– How do you manage inconsistency?
– What about traceability?.
6
RE draws from diverse disciplines

• Computer science
– logic formalisms – allow analysis of specifications
• Systems engineering
– characterizing systems
– identifying system boundaries
• And …
7
Philosophy
• Epistemology – understanding beliefs of stakeholders
• Phenomenology – what is observable in the world
• Ontology – what can be agreed on as objectively true
8
Cognitive psychology
• Provides an understanding
of the difficulties people
may have in describing
their needs.
• Domain experts utilize
subconscious knowledge
that they cannot articulate
leading to a mismatch
between their response to
questions and their actual
behavior.
9
Anthropology
• Observing human activities helps in understanding how computer systems
may help or hinder those activities.
– Ethnomethodology has been used to develop observational techniques for analyzing team-
working (also termed ethnography)
10
Sociology
• Understanding the political and cultural changes caused by technology.
• Introduction of a computer system can change many things:
– An organizations way of working
– An organizations structure
– Communication paths
– Even the original needs that it was built to satisfy
• Must ensure the process doesn’t become politicized possibly by involving
those most affected by the system
11
Linguistics
• RE is about communication.
• Ambiguity and misunderstanding is easy when natural language is used to
express requirements.
12
What is a requirement?
• Can range from a high-level, abstract statement of a service or constraint to
a detailed, formal specification.
• Why?
– Requirements may be basis for a bid so must be open to interpretation.
– Requirements may be part of the contract itself so must be defined in detail.
13
Requirement abstraction
• “If a company wishes to let a contract for a large software development
project, it must define its needs in a sufficiently abstract way that a solution
is not pre-defined. The requirements must be written so that several
contractors can bid for the contract, offering, perhaps, different ways of
meeting the client organization's needs. Once a contract has been awarded,
the contractor must write a system definition for the client in more detail so
that the client understands and can validate what the software will do. Both
of these documents may be called the requirements document for the
system.” (Davis, 1993)
14
Requirement separates the problem from the

solution
• A separate problem
description is
useful as it can
serve as a basis for
discussion with
stakeholders to see
if it corresponds to
their needs,
evaluating design
choices and
generating test
cases
Figures © Steve Easterbrook

15
But this is not a sequential process

• Requirements engineering is iterative; a complete problem specification
does not have to exist before the solution
• In fact, the problem statement is never fixed and change is inevitable
• Perfecting a problem statement may not be cost effective either
16
Requirements classification
• To cope with this duality we can classify requirements in terms of their
level of abstraction.
• Sommerville (2005) suggests:
– User requirements
– System requirements
– Software design specifications
17
User requirements
• Abstract statements written in natural language with accompanying
informal diagrams.
• Specify what services (user functionality) the system is expected to provide
and any constraints.
18
System requirements
• Detailed descriptions of the services and constraints.
• Should be structured and precise.
• Acts as contract between client and contractor.
• Sometimes referred to as functional specification or technical annex.
• Derived from analysis of the user requirements.
19
Software design specifications

• The analysis and design documentation used as basis for implementation
by developers.
• Derived from analysis of the system specification
20
Example
• User requirement
1. The software must allow a user to access, and subsequently bet on
individual sporting events
• System Requirement
1.1 The user should be presented with the available sporting events
1.2 Facilities should be provided to allow the user to search the available events
based upon the sport, the date/time or by competitor.
1.3 The software should allow users to select one or more events from the
selection.
1.4 The selected events should be presented along with the current odds
for each event and outcome.
1.5 The software should allow the user to place a bet on any of those
events in the selection.
1.6 The software should record that bet, updating the users account.
21
Another classification
• Functional requirements
• Non-functional requirements
• Domain requirements
22
Functional requirements
• The services the system should provide.
• How it will react to inputs.
• Sometimes state what the system should not do.
• Can be high-level and general (user requirements) or detailed, expressing
inputs, outputs, exceptions, etc. (system requirements)
23
Non-functional requirements
• Requirement imposed by the environment in which the system is to exist.
• This could mean timing constraints, quality properties, standard adherence,
programming languages to be used…
24
Non-functional requirement types
Non-functional
requirements
Product Organisational External

requirements requirements requirements
Portability
Efficiency Reliability Interoperability Ethical
requirements
requirements requirements requirements requirements
Usability Delivery Implementation Standards Legislative

requirements requirements requirements requirements requirements
Performance Space Privacy Safety

requirements requirements requirements requirements
25
Goals versus requirements

• Some NFRs are difficult to define precisely making them difficult to verify.
• Should distinguish goals from NFRs
Goal – a general intention of a stakeholder
The system should be easy to use by experienced operators
• Verifiable NFR – statement using some objective measure.
Experienced operators shall be able to use all the system functions after 2
hours of training
26
Domain requirements
• Derived from the application domain.
• May be:
– New functional requirements.
– Constraints on existing functional requirements.
– Specify how particular computations must be performed.
27
Train protection system

• The deceleration of the train shall be computed as:
Dtrain = Dcontrol + Dgradient
where Dgradient is 9.81ms2 * compensated gradient/alpha and where the

values of 9.81ms2 /alpha are known for different types of train.
28
Eh!
• The example highlights an important issue with domain requirements.
• They are often expressed by domain experts using domain-specific
terminology.
• They are used by software engineers unfamiliar with the intricacies of the
domain.
• Additionally, domain experts often leave out information from a
requirement as they understand the area so well.
29
User requirements
• Describe functional and non-functional requirements as they pertain to
externally visible behavior in a form understandable by clients and/or
system users.
• Use natural language, tables and simple intuitive diagrams.
30
Problems with natural language

• Lack of clarity
– Precision is difficult without making the document difficult to read
• Requirements confusion
– Functional and non-functional requirements tend to be mixed-up
• Requirements amalgamation
– Several different requirements may be expressed together
Hence the need for linguistics knowledge!
31
Example: database requirement

• The database shall support the generation and control of configuration
objects; that is, objects which are themselves groupings of other objects in
the database. The configuration control facilities shall allow access to the
objects in a version group by the use of an incomplete name.
• Fault: Includes both conceptual and detailed information

– Describes the concept of configuration control facilities
– Includes the detail that objects may be accessed using an incomplete name
32
Example: editor grid requirement

• 2.6 Grid facilities To assist in the positioning of entities on a diagram, the
user may turn on a grid in either centimeters or inches, via an option on the
control panel. Initially, the grid is off. The grid may be turned on and off at
any time during an editing session and can be toggled between inches and
centimeters at any time. A grid option will be provided on the reduce-to-fit
view but the number of grid lines shown will be reduced to avoid filling the
smaller diagram with grid lines.
• Fault: Grid requirement mixes three different kinds of requirement

– Conceptual, functional requirement states that the editing system should provide a grid and
presents the rationale.
– Non-functional requirement giving detailed information about grid units.
– Non-functional UI requirement which defines how that grid is switched on and off by user.
33
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,
– Use should for desirable requirements
• Use text highlighting to identify key parts of the requirement
• Avoid the use of technical language
34
Example: editor grid requirement

2.6 Grid facilities
2.6.1 The editor shall provide a grid facility where a matrix of horizontal
and vertical lines provide a background to the editor window. This
grid shall be a passive grid where the alignment of entities is the user's
responsibility.
Rationale: A grid helps the user to create a tidy diagram with well-spaced
entities. Although an active grid, where entities 'snap-to' grid lines can be
useful, the positioning is imprecise. The user is the best person to decide
where entities should be positioned.
35
Example: editor node requirement

3.5.1 Adding nodes to a design
3.5.1.1 The editor shall provide a facility for users to add nodes of a
specified type to their design.
3.5.1.2 The sequence of actions to add a node should be as follows:
1. The user should select the type of node to be added.
2. The user should move the cursor to the approximate node position
in the diagram and indicate that the node symbol should be added at
that point.
3. The user should then drag the node symbol to its final position.
Rationale: The user is the best person to decide where to position a node on
the diagram. This approach gives the user direct control over node type
selection and positioning.
36
System requirements
• More detailed specifications of user requirements
• Serve as a basis for designing the system
• May be used as part of the system contract
• System requirements may be expressed using system models (first iteration
of analysis models)
37
More 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 modularization
– NL structures are inadequate to structure system requirements
38
Alternatives to natural language
Notation Description
Structured This approach depends on defining standard forms or
natural templates to express the requirements specification.
language
Design This approach uses a language like a programming language
description but with more abstract features to specify the requirements by
languages defining an operational model of the system.
Graphical A graphical language, supplemented by text annotations is
notations used to define the functional requirements for the system. An
early example of such a graphical language was SADT
(Schoman and Ross, 1977). More recently, use-case
descriptions (Jacobsen, Christerson et al., 1993) have been
used.
Mathematical These are notations based on mathematical concepts such as
specifications finite-state machines or sets. These unambiguous
specifications reduce the arguments between customer and
contractor about system functionality. However, most
customers don’t understand formal specifications and are
reluctant to accept it as a system contract.
39
Structured language specification

• A limited form of natural language may be used to express requirements
• This removes some of the problems resulting from ambiguity and
flexibility and imposes a degree of uniformity on a specification
• Often best supported using a forms-based approach
40
Form-based specification
• Include the following information:
1. Definition of the function or entity
2. Description of inputs and where they come from
3. Description of outputs and where they go to
4. Indication of other entities required
5. Pre- and post-conditions (if appropriate)
6. The side effects (if any)
41
Example: form-based node specification

Function Add node
Description Adds a node to an existing design. The user selects the
type of node, and its position. When added to the
design, the node becomes the current selection. The
user chooses the node position by moving the cursor to
the area where the node is added.
Inputs Node type, Node position, Design identifier
Outputs Design identifier
Destination The design database. The design is committed to the
database on completion of the operation.
Requires Design graph rooted at input design identifier
Pre-condition The design is open and displayed on the user's screen
Post-condition The design is unchanged apart from the addition of a
node of the specified type at the given position
Side-effects None
42
PDL-based requirements definition

• Requirements may be defined operationally using a language like a
programming language but with more flexibility of expression
• Most appropriate in two situations
– Where an operation is specified as a sequence of actions and the order is important
– When hardware and software interfaces have to be specified
• Disadvantages are
– The PDL may not be sufficiently expressive to define domain concepts
– The specification will be taken as a design rather than a specification
– Notation is only understandable to people with programming language knowledge
43
Part of ATM specification
class ATM {
// declarations here
public static void main (String args[]) throws InvalidCard {
try {
thisCard.read () ; // may throw InvalidCard exception
pin = KeyPad.readPin () ; attempts = 1 ;
while ( !thisCard.pin.equals (pin) & attempts < 4 )
{ pin = KeyPad.readPin () ; attempts = attempts + 1 ;
}
if (!thisCard.pin.equals (pin))
throw new InvalidCard ("Bad PIN");
thisBalance = thisCard.getBalance () ;
do { Screen.prompt (" Please select a service ") ;
service = Screen.touchKey () ;
switch (service) {
case Services.withdrawalWithReceipt:
receiptRequired = true ;
44
Interface specification
• Most systems must operate with other systems and the operating interfaces
must be specified as part of the requirements
• Three types of interface may have to be defined
– Procedural interfaces
– Data structures that are exchanged
– Data representations
• Formal notations are an effective technique for interface specification
45
PDL interface specification

interface PrintServer {

// defines: an abstract printer server
// requires: interface Printer, interface PrintDoc
// provides: initialize, print, displayPrintQueue,
cancelPrintJob, switchPrinter

void initialize ( Printer p ) ;
void print ( Printer p, PrintDoc d ) ;
void displayPrintQueue ( Printer p ) ;
void cancelPrintJob (Printer p, PrintDoc d) ;
void switchPrinter (Printer p1, Printer p2, PrintDoc d) ;
} //PrintServer
46
The requirements document

• The requirements document is the official statement of what is required of
the system developers
• Should include both a definition and a specification of requirements
• It is NOT a design document. As far as possible, it should be a set of
WHAT the system should do rather than HOW it should do it
47
Users of requirements document

Specify
Specifythe
therequirements
requirementsandandread
readthem
themtoto
check
checkthat
thatthey
theymeet
meettheir
theirneeds.
needs.They
They
Customers
Customers specify changes to the requirements
specify changes to the requirements
Use
Usethe
therequirements
requirementsdocument
documenttotoplan
planaa
Managers
Managers bid
bidfor
forthe
thesystem
systemand
andtotoplan
planthe
thesystem
system
development
developmentprocess
process
Use
Usethe
therequirements
requirementstotounderstand
understandwhat
what
Developers
Developers system is to be developed
system is to be developed
Use
Usethe
therequirements
requirementstotodevelop
developvalidation
validation
Test
Testengineers
engineers tests
testsfor
forthe
thesystem
system
Use
Usethe
therequirements
requirementstotohelp
helpunderstand
understand
Maintenance
Maintenanceengineers
engineers the
the system and the relationshipbetween
system and the relationship betweenits
its
parts
parts
48
Requirements for a requirements document

• Specify external system behaviour
• Specify implementation constraints
• Easy to change
• Serve as reference tool for maintenance
• Record forethought about the life cycle of the system i.e. predict changes
• Characterize responses to unexpected events
49
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 in natural language, tables and
diagrams
• System requirements are intended to communicate the functions that the
system should provide
• System requirements may be written in structured natural language, a PDL
or in a formal language
• A software requirements document is an agreed statement of the system
requirements
50
References
• A. Davis, Software Requirements: Objects, Functions and States, Second
Edition, Upper Saddle River, NJ: Prentice-Hall, 1993.
• B. Nuseibeh and S. Easterbrook,“Requirements Engineering: A Roadmap”,
Proceedings of the International Conference on Software Engineering,
Limerick, Ireland, June 2000, pp. 35 – 46.
• I. Sommerville, Software Engineering, 7th ed., Boston, MA: Addison-
Wesley, 2005.
• P. Zave, “Classification of Research Efforts in Requirements Engineering,”
ACM Computing Surveys, 29(4), pp 315 – 321.
51

Requirements Engineering Fundamentals

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Requirements Engineering Fundamentals

Загружено:

Авторское право:

Доступные форматы

SWENG 580: advanced software engineering

What is requirements engineering ?

What is requirements engineering?

“real world goals”

“evolution over time and across software

• Planning and Eliciting requirements.

RE draws from diverse disciplines

Requirement separates the problem from the

Figures © Steve Easterbrook

But this is not a sequential process

Software design specifications

Non-functional requirement types

Product Organisational External

Usability Delivery Implementation Standards Legislative

Performance Space Privacy Safety

Goals versus requirements

Goal – a general intention of a stakeholder

The system should be easy to use by experienced operators

• Verifiable NFR – statement using some objective measure.

Train protection system

where Dgradient is 9.81ms2 * compensated gradient/alpha and where the

Problems with natural language

Hence the need for linguistics knowledge!

Example: database requirement

• Fault: Includes both conceptual and detailed information

Example: editor grid requirement

• Fault: Grid requirement mixes three different kinds of requirement

Guidelines for writing requirements

Example: editor grid requirement

Example: editor node requirement

More problems with NL specification

Alternatives to natural language

Structured language specification

Example: form-based node specification

PDL-based requirements definition

Part of ATM specification

PDL interface specification

The requirements document

Users of requirements document

Requirements for a requirements document

Вам также может понравиться