Download - INFO 637Lecture #51 Software Engineering Process II Defining Requirements INFO 637 Glenn Booker
INFO 637 Lecture #5 2
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)
INFO 637 Lecture #5 3
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
INFO 637 Lecture #5 4
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.)
INFO 637 Lecture #5 5
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?
INFO 637 Lecture #5 6
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
INFO 637 Lecture #5 7
Reliability Requirements
Reliability requirements may specify goals for mean time between failures (MTBF), recoverability, and predictability of results Particularly used for mission-critical systems
INFO 637 Lecture #5 8
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)
INFO 637 Lecture #5 9
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.)?
INFO 637 Lecture #5 10
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
INFO 637 Lecture #5 11
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
INFO 637 Lecture #5 12
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
INFO 637 Lecture #5 13
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
INFO 637 Lecture #5 14
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
INFO 637 Lecture #5 15
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
INFO 637 Lecture #5 16
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?
INFO 637 Lecture #5 17
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
INFO 637 Lecture #5 18
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
INFO 637 Lecture #5 19
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
INFO 637 Lecture #5 20
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
INFO 637 Lecture #5 21
Extracting Requirements
Define operating environment Assess business issues Define domain constraints Record requirements rationale Prototype poorly understood requirements Define usage scenarios Define operational processes
INFO 637 Lecture #5 22
Another Example
The sample RFI includes examples of functional requirements, constraints, and meaningless jabber See Sample SIR handout
Can you tell them apart?
INFO 637 Lecture #5 23
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
INFO 637 Lecture #5 24
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
INFO 637 Lecture #5 25
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)