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