info 637lecture #51 software engineering process ii defining requirements info 637 glenn booker

INFO 637 Lecture #5 1

Software Engineering Process IIDefining Requirements

INFO 637

Glenn Booker


What are Requirements?

Requirements describe key characteristics and capabilities desired for your product

Requirements include functions your product can perform (functional requirements), and every other aspect of your product or how it was created (non-functional requirements)


Requirements Scope

Requirements can cover not only your product (which may include software, hardware, and networking components) but also: Documentation Training The process for creating the product Service or maintenance


FURPS+

One way of describing requirements is using the FURPS+ breakdown F is for Functional U is for Usability R is for Reliability P is for Performance S is for Supportability The “+” is for everything else

(Stolen from Larman’s Applying UML and Patterns, 2nd ed.)


Functional Requirements

Functional Requirements include every method of obtaining input, processing inputs, and generating outputs

Often this is the most complex list of requirements

Directly relates to system-level testing after product is completed – can each requirement be met?


Usability Requirements

Usability requirements describe how your product was designed to accommodate interaction with humans

Includes human factors, types of help available, and documentation

Some non-functional requirements may be testable, others not


Reliability Requirements

Reliability requirements may specify goals for mean time between failures (MTBF), recoverability, and predictability of results Particularly used for mission-critical systems


Performance Requirements

Performance relates here to how fast or how much the product can accomplish

These typically include response time for queries, volume of throughput, and/or resource usage (e.g. in terms of CPU, disk, memory, or network traffic)


Supportability Requirements

How easy is it to support this system?How easy is it to adapt to new needs,

or be reconfigured?How easy is it to maintain?Can it adapt to other countries

(e.g. language, power needs, etc.)?


Other Requirements

The “+” includes other kinds of requirements: Implementation constraints (hardware,

resources, etc.) Interfaces to external systems (which you

don’t control) Operations; how is it used operationally? Packaging; how is it shipped? Legal; export and licensing issues


Constraints

Requirements can include constraints on your product or how it is created Comply with existing PC’s, or development

environment, or database system Comply with business rules Comply with physical or logistical constraints Must be developed by a woman-owned, CMM

level three small business (for example!) Or any other kind of constraint


Software Requirements Spec

Requirements can be captured in a Software Requirements Specification (SRS)

The SRS can also be used as a contract, binding the developer to commit to exactly what they will create for the customer Helps avoid misunderstandings and unhappy

customers by making expectations clearer


Communication is the Key

While a good SRS is very helpful, the bigger need is for the developers and customer to communicate with each other Driving 100 mph in the wrong direction won’t

get you to your destination and faster! Similarly, starting development without knowing

what you need to create won’t help you finish quickly


Requirements Change

Even projects with “well known requirements” from the beginning typically have 30% of those requirements change before the project is completed

Must expect requirements will change, and create a process to control those changes


Requirements Change

Changes cost time and effort – need to quantify those to know how much cost to expect Otherwise it’s like taking your car to a mechanic

and telling them to do whatever they wantOften a Configuration Control Board

(CCB) is used to determine whether a particular change is acceptable


Change Control

To determine if a change is needed, follow some sort of process See Change Control handout

First step is to screen or scrub the proposed change Do we understand what is suggested? Is it really needed? Has someone already suggested it?


Change Control

Then we need to estimate how much work the change will be Estimate size, cost, and effort needed to

implement it Determine who could best implement it Determine its priority

Then start implementing the change after approval by the CCB


Change Control

The developers create the change, do unit testing, and get peer review approval of the change

Once ready, the CCB may determine when the change will be implemented (often the next available build)

Many changes may be built together, and tested to make sure they all work


Change Control

Then the CCB reviews the system test results, and approves release of the change

The change is now part of the new system baseline

Process is very similar for software system maintenance, not just development


Extracting Requirements

Requirements are obtained (elicited) by working from the most clearly understood aspects to the most vague Assess system feasibility Understand organizational issues Identify system stakeholders Record requirements sources


Extracting Requirements

Define operating environment Assess business issues Define domain constraints Record requirements rationale Prototype poorly understood requirements Define usage scenarios Define operational processes


Another Example

The sample RFI includes examples of functional requirements, constraints, and meaningless jabber See Sample SIR handout

Can you tell them apart?


SRS Structure

Many different structures are available for an SRS The text’s is on page 113 An SRS may range from a few pages long

to hundreds

The SRS may be used to write system-level test procedures, to test whether every requirement works in the final product


SRS Script

The development script for creating the SRS includes: Reviewing and clarifying the system needs Allocating parts of the SRS to be done by

each team member Developing the system test plan Inspecting the SRS and test plan Refining the SRS and test plan


End Product

This phase results in a completed (baselined) SRS and the system test plan While simple in concept, these control

everything which happens from this point on

They are now baselined documents, so changes to them need to be submitted via the change process (form CCR)

info 637lecture #51 software engineering process ii defining requirements info 637 glenn booker

Documents

kinds of requirements

requirements scoperequirements

systemlevel testing

mean time

business rulescomply

response time

small business

cmm level