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
� EMBED Unknown ���
_1389374183.bin