Chapter 4 – Requirements Engineering
-- establishing the services that the customer requires from a system and constraints under which
it operates and is developed
What is a requirement?
- a high-level abstract statement of a service or system constraint
- a detailed mathematical function specification
These are not really consistent, therefore sometimes separated into User Requirements and
System Requirements/Technical specifications
Functional vs. Non-functional requirements
Functional – statement of services system must provide – how system should react to specific
inputs and how system should behave in certain situations – may also state what the
system should not do – if not precisely stated, they may be interpreted differently among
constituents
Non-functional – constraints on services or functions offered by system – ie timing constraints,
constraints on development process, standards, environment, etc. – often apply to entire
system rather than individual feature/service -- 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
These can be further characterized as:
Design Constraints – design decision that restricts set of solutions to the problem
Process Constraints – restriction on the techniques or resources used to build the system
Quality Constraints – describes a quality characteristic
Handout:: Pfleeger and Atlee
Exercise: Classify each as a functional requirement, a quality constraint, design constraint or
process constraint.
a) The client daemon must be invisible to the user
b) The system should provide automatic verification of corrupted links or outdated data
c) An internal naming convention should ensure that records are unique
d) Communication between the database and servers should be encrypted
e) Relationships may exist between title groups [a type of record in the database]
f) Files should be organizable into groups of file dependencies
g) The system must interface with an Oracle database
h) The system must handle 50,000 users concurrently
Need to make sure that non-functional requirements are verifiable – sometimes they are difficult
to state precisely
Examples:
Water quality information must be accessible immediately.
Water quality records must be retrieved within 5 seconds of the request.
The system should be easy to use by medical staff and should be organized in such
a way that user errors are minimized.
Medical staff shall be able to use all the system functions after four hours of
training. After this training, the average number of errors made by experienced
users shall not exceed two per hour of system use.
Property
Measure
Speed
Processed transactions/second
User/event response time
Screen refresh time
Size
Mbytes
Number of ROM chips
Ease of use
Training time
Number of help frames
Reliability
Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness
Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability
Percentage of target dependent statements
Number of target systems
The software requirements document
-- official statement of what is required of the system developers
-- should include both a definition of user requirements and a specification of the system
requirements
-- NOT a design document - set of WHAT the system should do rather than HOW it should do it
Users of a requirements document
Handout:: proposed Requirements and Specification document
Ways of writing a system requirements specification – page 95 of text
Modeling Notations
ER Diagrams – entity-relationship diagrams
Entity – rectangles, collection of objects that have common properties and behaviors
Relationships – edge between entities, how entities interact with one another, may be 1..1, 1..N,
M..N
Attributes – sometimes appear as tags on entity or inside of the rectangle, describes data or
properties associated with the entity
UML Class Diagrams – a form of ER diagram – relates the classes (entities) in the specification
Class – box in the diagram represents a collection of similarly typed entities
Class has a name, a set of attributes (simple data variables), and a set of operations
Class-scope attribute – underlined attribute, is a data value shared by all instances of the
class
Class-scope operation – underlined operation, operation performed by abstract class,
rather than instances of the class
Association – line between two classes that represents the relationship between the
classes
Aggregate associations – open diamond on one end – “has-a” relationship – one
class is a property or element of another class – ie. Association between Patron
and their Credit Card
Composition association – closed diamond on one end – instances of the class
are constructed from instances of the component classes – ie. A bike consists of
wheels, gears, pedals, handlebar, seat)
Generalization association – triangle on one end – “is-a” relationship – subtype
– parent class and subclasses – subclass inherits attributes, operations and
associations of parent class
Role name – specifies context of an entity with respect to particular association
Multiplicities – specifies constraints on the number of entities
Association Class – relates attributes and operations to an association – these
cannot be attributed solely to the classes in the association
Exercise:: Elevator Case Study
A product is to be installed to control n elevators in a building with m floors. The problem
concerns the logic required to move elevators between floors according to the following constraints:
1. Each elevator has a set of m buttons, one for each floor. These illuminate when pressed and cause
the elevator to visit the corresponding floor. The illumination is canceled when the
corresponding floor is visited by the elevator.
2. Each floor, except the first floor and the top floor, has two buttons, one to request an up-elevator
and one to request a down-elevator. These buttons illuminate when pressed. The illumination is
canceled when an elevator visits the floor and then moves in the desired direction.
3. When an elevator has no requests, it remains at its current floor with the doors closed.
Create a UML class diagram for the elevator problem.
Event Traces
-- graphical description of a sequence of events that are exchanged between real-world entities
vertical line – timeline for a distinct entity
horizontal line – represents event or interaction between the entities (often represents a message
passed between the entities
each graph depicts a single trace – below represents turnstile problem (left is typical behavior,
right is exceptional behavior)
Message Sequence Charts – type of event trace – includes facilities for creating and destroying
entities
vertical line – represents entity
message – arrow from sending entity to receiving entity – arrow’s label specifies message
name and data parameters (if any)
If message arrow slopes downwards, this represents passage of time between sent
and received
dashed arrow – entity is being created
cross at end of vertical line – end of entity’s execution
solid rectangle at end of vertical line – end of entity’s specification without
meaning the end of its execution
actions – show invoked operations or changes to variable values – represented by
rectangles on vertical line
conditions – important states in entity’s evolution – represented as labeled hexagons
Exercise:: Develop a scenario for making a hotel reservation. Describe the process in paragraph
form first. Then you should model the process using a message sequence chart.
State Machines – used to represent collections of event traces in a single model – graphical
description of all dialog between the system and its environment
State – or node represents a stable set of conditions that exist between event occurrences
Transition – represents a change in the behavior or condition due to the occurrence of an
event – transition is labeled with the triggering event and possibly with an output event
Useful for specifying the dynamic behavior of a process and for describing how behavior
should change in response to events
UML Statechart Diagrams – a state diagram that depicts dynamic behavior of the objects in a
UML class diagram – UML class diagram gives a static, big picture view of the problem
in terms of the entities involved and their relationships – it says nothing on how the
entities behave or change in response to input events
UML model is a collection of concurrently executing statecharts – one per instantiated
object that communicate via message passing – every class in a UML class diagram has
an associated statechart that specifies the behavior of the objects in the class
Transition label syntax: event(args) [condition] / action* ^Object.event(args)*
event – trigger and may carry arguments
condition – predicate on object’s attribute values
action – each prefaced with a (/) specifies assignments made to object’s attributes
output event – may carry parameters and is designated for a target object or broadcast to
all objects
“*” – transition may have many actions or generate many output events
Exercise: Create a UML statechart for the elevator problem above.
Petri Nets – form of state transition notation used to model concurrent activities and their
interactions
places – circles in the net that represent activities or conditions
bars – represent transitions
arcs – connect a transition with input places and output places
tokens – populate places and act as enabling conditions for transitions
weight – assigned to arc and specifies how many tokens to remove from input place or
inserted into arc’s output place when transition fires
Data-flow Diagrams – model functionality and flow of data from one function to another –
these differ from above approach as they show high-level functionality of a single model
that can then be decomposed
process – bubble in the diagram – data transformer
data flow – arrow – into bubble – input to the process – out of bubble – output to the
process
data store – parallel lines – formal repository
data sources/sinks – rectangles – provide data or receive output
Exercise: Create a DFD for an online telephone directory to replace the phonebook provided by
the phone company. The directory should be able to provide phone numbers when
presented with a name; list the area codes for different parts of the country and generate
emergency phone numbers for the area.
UML Use-case – similar to a DFD that shows observable, user-initiated functionality in terms of
interactions between system and its environment – used to specify user views of essential
system behavior
Box – represents the system boundaries
Stick figures – represent actors (both human and system)
Oval – inside box represents major required functionality
Line between actor and use case – indicates actor participates in the use case
Dashed line – from base case to sub case
Each use case encompasses several possible scenarios – these scenarios are usual described in
text and include the following:
Name of use case
Actors
Goal of use case
Preconditions
Postconditions
Trigger
Description of Scenario (numbered list)
Sample Use-case description (not associated with above diagram)
Exercise:: Create a use case for the following:
Automated library circulation system. Every book has a barcode, and every borrower has a
card bearing a barcode. When a borrower wishes to check out a book, the librarian scans
the barcodes on the book and the borrower’s card, and enters a C at the computer
terminal. Similarly, when a book is returned, it is again scanned and the librarian enters
R. Librarians can add books (+) to the library collection or remove books (-).
Borrowers can go to a terminal and determine all the books in the library by a particular
author (the borrower enters A = followed by the author’s name), all the books with a
specific title (T = followed by the title), or all the books in a particular subject area (S =
followed by the subject area). Finally, if a borrower wants a book currently checked out,
the librarian can place a hold on the book so that when it is returned, it will be held for
the borrower who requested it (H = followed by the number of the book).
Ways to write System Specs
Notation
Description
Natural language
The requirements are written using numbered sentences in natural
language. Each sentence should express one requirement.
Structured natural
language
The requirements are written in natural language on a standard form
or template. Each field provides information about an aspect of
the requirement.
Design description
languages
This approach uses a language like a programming language, but with
more abstract features to specify the requirements by defining
an operational model of the system. This approach is now rarely
used although it can be useful for interface specifications.
Graphical notations
Graphical models, supplemented by text annotations, are used to define
the functional requirements for the system; UML use case and
sequence diagrams are commonly used.
Mathematical
specifications
These notations are based on mathematical concepts such as finite-state
machines or sets. Although these unambiguous specifications can
reduce the ambiguity in a requirements document, most
customers don’t understand a formal specification. They cannot
check that it represents what they want and are reluctant to
accept it as a system contract
Requirements Engineering Processes
-- processes depend on the application domain – however, there are a number of generic
activities common to all processes
Requirements elicitation -- technical staff working with customers to find out about
application domain, the services that the system should provide and the system’s
operational constraints
Interviewing – can be formal or informal
Scenarios – real-life examples of how system can be used – describes
normal flow of events and describes what can go wrong
Use cases
Requirements analysis -- Requirements classification and organization -- Prioritization
and negotiation -- resolving requirements conflicts
Requirements validation -- concerned with demonstrating that requirements define the
system that the customer really wants -- requirements error costs are high so
validation is very important (fixing a requirements error after delivery may cost
up to 100 times the cost of fixing an implementation error)
Requirements Reviews – manual analysis of requirements
Prototyping – executable model of system
Test-case generation – develop tests to check testability
Requirements management -- Requirements management is the process of managing
changing requirements during the requirements engineering process and system
development
-- in practice, Requirements Engineering is an iterative activity