Software Engineering Process II

1
Software Engineering Process II

• Defining Requirements
• INFO 637
• Glenn Booker

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)

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

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 Larmans Applying UML and Patterns,
2nd ed.)
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?

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

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

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)

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.)?

10
Other Requirements

• The includes other kinds of requirements
• Implementation constraints (hardware, resources,
  etc.)
• Interfaces to external systems (which you dont
  control)
• Operations how is it used operationally?
• Packaging how is it shipped?
• Legal export and licensing issues

11
Constraints

• Requirements can include constraints on your
  product or how it is created
• Comply with existing PCs, 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

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

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 wont get
  you to your destination and faster!
• Similarly, starting development without knowing
  what you need to create wont help you finish
  quickly

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

15
Requirements Change

• Changes cost time and effort need to quantify
  those to know how much cost to expect
• Otherwise its like taking your car to a mechanic
  and telling them to do whatever they want
• Often a Configuration Control Board (CCB) is used
  to determine whether a particular change is
  acceptable

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?

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

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

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

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

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

22
Another Example

• The sample RFI includes examples of functional
  requirements, constraints, and meaningless jabber
• See Sample SIR handout
• Can you tell them apart?

23
SRS Structure

• Many different structures are available for an
  SRS
• The texts 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

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

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)