INFO 627Lecture #61 Requirements Engineering and Management INFO 627 Refining the System Definition...

INFO 627 Lecture #6 1

Requirements Engineeringand ManagementINFO 627

Refining the System Definition

Glenn Booker


Requirements Now that we have a good idea of the

customer needs, have defined the main features for our system, and selected a structure for managing the implementation of those features…*whew*

We can now work on refining requirements to guide development and testing


Requirements As we define and refine requirements, it must

be clear that the written description of those requirements is the only authority as to what we are creating

And changes in scope or intent need to be reflected immediately

We started by defining features vaguely – now we add details


Requirements The system must fulfill user needs The system requirements must be complete

and consistent, and fit in the environment where it will live

Definition of requirements also supports detailed feasibility study, to ensure we are making a wise investment


Requirements How precise requirements need to be depends

on the type of application and the industry it supports We hope that aircraft flight control software is

designed more carefully than Microsoft Word Goal is to produce understandable

requirements to support meeting user needs


Requirements Many methods or models can be used

to express requirements Use Cases Natural language Formal methods (Z or Larch)

Storage and management of those requirements could be in a spreadsheet or database


Requirements Requirements need to be:

Understood by all parties concerned Specific enough to be verified

and demonstrated From the beginning, think of requirements in

terms of being able to prove whether they have been fulfilled (“Trust but verify”)


Software Requirements Software requirements are generally related to

some capability the user needs to have, or some capability the systems needs for some other reason

Inputs and outputs are good places to start looking for requirements

Don’t forget non-functional requirements!


Software Requirements Think of the system as a black box, and focus

on what needs to go into and leave the system Five major classes of things can describe a

system (per Davis) Inputs to the system, in terms of content, format,

and source


Software Requirements Outputs from the system, including the type of

output device, and format of the outputs Functions of the system, to accept inputs and/or

create outputs Attributes of the system, such as the “–ilities”,

throughput, and performance Attributes of the system environment, such

as where it is used, and compatibility with other systems


Software Requirements Using this kind of breakdown helps

ensure completeness of requirements Also can use these categories to

help determine if something really is a requirement

Features lead to one or more requirements So requirements help to define the scope

and exact capabilities of features


Mapping Features to Requirements We need to trace the origin of requirements

from their corresponding features This traceability helps ensure we define

complete requirements All features result in one or more requirements [Side note: Microsoft products don’t recognize

“traceability” as a word…does that tell us something about their products?]

1E p. 231


What Requirements Are Not The challenge in writing requirements

is to avoid things which shouldn’t impersonate requirements Project management information Unneeded design or implementation details Testing information

Requirements should focus on system behavior, not its inner workings


Project Management Information Requirements should not include

Budget, staffing, or schedule information Configuration management plans Testing plans (except maybe hints for very

unusual cases) Put these in separate Program Management

Plan, CM Plan, etc.


Unneeded Design Details Do not define the system design or

architecture as requirements Reduces the creativity of the developers

to use an even better approach Includes specifying development language, tools,

design methodology (e.g. OO vs. relational database)


Design Constraints If an aspect of the system design is artificially

constrained BY THE CUSTOMER, make it a design constraint Only if the customer mandated it

Other design decisions should only appear in design documents, not hiding among requirements E.g. if using VB is the best language


Testing Plans Requirements do not include

Test plans Verification and validation plans Test cases

In very rare cases, a testing approach may be hinted at or suggested if a suitable approach may not be obvious


Implied Requirement Details Beware of stating assumptions about the form

or format of an input or output E.g. an output might be assumed to be on paper,

but why not a web page or PDF file? Be clear what assumptions are made about the

environment the user will have Don’t necessarily have a keyboard and mouse


Requirements vs. Design Requirements (what the system does) should

be determined before design Requirements are determined by the users and

customers, since they (generally) know their needs best

Design (how) is done by technical experts, because they know the options available


Requirements vs. Design Yet trying to implement requirements may

lead to a design which alters the req’ts Hence in reality, design and requirements are

iterative, feeding off each other until an acceptable balance is achieved

Changes in technology can drastically affect requirements (client/server vs. web)


Types of Requirements A basic breakdown of requirements

may include: Functional software requirements Non-functional software requirements Design constraints

Functional requirements focus on actions (user does x, system does y)

1E p. 237

See also lecture 2, INFO 620 for the FURPS+ model


Non-Functional Requirements Non-functional requirements typically

include: Usability

Time needed for training Time to perform task Usability compared to other systems Availability of help Compliance with HCI standards (Windows, Mac)


Non-Functional Requirements Reliability

Availability (%) Mean time between failures (MTBF, hours) Mean time to repair (MTTR, hours) Accuracy (numeric precision, number of decimals) Defect rate (defects/1000 lines of code) Bugs per type (number of bugs by severity)


Non-Functional Requirements Performance

Response time for a transaction – average, maximum, some % below some value

Throughput (transactions per second) Capacity (number of simultaneous users) Degraded modes of operation (what are performance

expectations if system is partially offline)


Non-Functional Requirements Supportability

Expected implementation time for minor, medium, and major enhancements

Planned or possible future enhancements mostly affect design decisions


Design Constraints We generally want to define requirements so

that several design approaches might be used to implement them

Constraints might need to be imposed such as the development language, use of corporate reuse libraries, coding standards, or external standards such as FDA, DOD or FCC regulations


Design Constraints Should distinguish constraints from

requirements, such as using a “DC” prefix, and isolate them from the true requirements

Identify the source of each constraint, and why it was imposed (if known)


Parent-Child Requirements A child requirement specifies details about

its parent Could look on as the parent is a requirement,

and the child a specification Don’t go crazy with lots of grandchildren and

great-grandchildren – usually not worth the effort


Use Case Refinement Use cases make sense particularly when a

system has lots of functions to perform, and you’re using an OO methodology

If there are few users or interfaces, or extensive non-functional requirements, might not be the best choice


Use Case Refinement Use cases focus on who does something

(actor), how they interact with the system, and what the system does in response (including tasks like saving data, displaying a report, etc.)

Use case must be of value to the actor Name each use case clearly and concisely


Use Case Refinement Refinement of use cases may include:

The basic flow, or main success scenario Variants or alternative flows – such as different

methods of payment, processing personal versus business orders, or error conditions

Preconditions – what happens before this use case may be used?

Postconditions – what has changed as a result of this use case?


Software Requirements Specification (SRS) A Software Requirements Specification

(SRS) defines the conceptual model of what the system will be

Main standard is IEEE 830:1998 SRS isn’t always a single document, but

a collection of documents and models Is a living package; evolves with the system


SRS Purpose The SRS serves to communicate among the

developers and various stakeholders Represents an agreed contract as to what will

and won’t be in the system Provides a basis for tracking completion of

the system Feeds design, testing, training, etc.


SRS Ownership The SRS is owned by the developers Often each part may have a separate owner

who is responsible for that part All are overseen by the Vision champion,

chief architect, and the program manager


SRS Format There are many ways to arrange the contents

of an SRS Text provides one structure (1E pp. 266-267),

which assumes you are using use cases IEEE 830 provides another (p. 11 therein), which

is more generalized Not all sections apply to every system; use

“Not Applicable” if that’s the case


SRS Contents Some parts of the SRS look like Vision

contents – purpose, scope, constraints, interfaces, documentation and help – but here the latter are described in more detail

Other issues are now addressed – licensing and legal issues, purchased components (implying some design concept), and all requirements are identified (not just key)


SRS Contents The main body of the SRS is a detailed

description of the functional and non-functional requirements

Functional requirements can be broken down many ways


Functional Requirements Functional requirements may be organized

(IEEE 830, App. A) by: Mode of operation of the system; best used for

software-intensive mechanical systems, each mode’s functional requirements are detailed (scanning mode, editing mode, acquisition mode, etc.) If needed, each mode’s interfaces, functional, and

performance requirements can be addressed


Functional Requirements User class; where each type of user of the system

has well defined activities they must perform, then their functional requirements are listed

Class; for object oriented systems; each class is described in terms of its attributes, methods, and messages


Functional Requirements Feature; similar to use case descriptions, identify

when and how each feature is to be used, and the functional requirements for each feature

Stimulus; useful when the system’s responses (functional requirements) are based on what kind of specific stimulus or message it receives


Functional Requirements Functional hierarchy; break the requirements

down by information flow, process, or data construct, and provide a data dictionary to specify each data element’s format; good for reengineering legacy information systems

Or any combination of the above methods (multiple organizations), such as mixing user class then stimulus and response


Non-Functional Requirements Non-functional requirements can be

documented according to the structure already outlined Usability Reliability Performance Supportability


Balancing Requirements We need to review requirements for

Consistent level of detail throughout the system Adequate level of detail to guide implementation,

without over constraining that implementation Most of the SRS is text; graphics can be

helpful but beware of adding implied design

INFO 627Lecture #61 Requirements Engineering and Management INFO 627 Refining the System Definition...

Documents

Transcript of INFO 627Lecture #61 Requirements Engineering and Management INFO 627 Refining the System Definition...