Chapter 05: Evolutionary Requirements

1
Chapter 05 Evolutionary Requirements

• 5.1. Definition Requirements
• Requirements are capabilities and conditions to
  which the system, and more broadly the project,
  must conform
• The UP does not attempt to fully define the
  requirements before programming but instead,
  promotes a systematic approach to finding,
  documenting, organising and tracking the changing
  requirements of a sytem
• This is about embracing change
• Tackling software development as a problem
  solving activity
• It also emphasises a disciplined way to handling
  change iteratively and skillfully yes but not in
  an haphazard or sloppy way.
• The UP-way entails continuous, multi-way,
  communication between the developpers, the
  clients and all other stakeholders to discover
  and track requirements but also the documenting
  of requirements the UP manage changing
  requirements.

2

• 5.2 Evolutionary vs. Waterfall Requirements
• The UP embraces change in requirements, the
  Waterfall model tries to deny that requirements
  will change by requesting that a full, detailed,
  specification be written prior to design and
  coding.
• On average 25 of the requirements change during
  a software project
• Writing a detailed, accurate, specification even
  with frozen requirements with difficult and error
  prone (which means that the actual requirements
  are not actually captured implying change anyway
  later on in the specification)
• Why do you think people tried the waterfall-way
  of doing things (and still do)?
• In the UP and other evolutionary methods, we
  start release-grade programming and testing long
  before most of the requirements have been
  analysed (perhaps only 10 of the requirements
  have been specified whenever coding starts).

3

• The UP does not advocate that the solution is to
  start coding on day two of the project and forget
  about requiremenst analysis or requirements
  documentation
• There is a middle way iterative and evolutionary
  requirements analysis combined with early
  time-boxed iterative development and frequent
  stakeholder participation, evaluation, and
  feedback on partial results
• It not easier to do than writing the full
  requirements up-front
• It is just more likely to succeed

4

• 5.3 Means to Find Requirements?
• Surely the client will know them all
• Do they?
• Eliciting the real requirements is in general
  difficult. You must use whatever technique is
  necessary
• Writing use cases
• Requirements workshop
• Maximum involvement of the client
• Prototypes
• Focus groups with proxy customers
• Increment demonstration after each iteration
• Active feedback solicitation
• Friendly client/developers team building
• Good communication practices

5

• 5.4 Types and Categories of Requirements
• In the UP requirements are categorised according
  to the FURPS model
• Functional features
• Usability human factors, help, documentation
• Reliability frequency of failure,
  recoverability
• Performance response times, throughput,
  resource usage
• Supportability adaptability, maintainability,
  internationalisation
• in addition the the in FURPS indicates
  ancillary requirements or constraints such as
• Implementation language and tools, hardware
  restrictions
• Interface interfacing constraints
• Packaging physical box
• Legal licensing
• Another, much coarser, categorisation is
  functional and non-functional requirements.

6

• Categories are good (up to a point ) as a
  checklist we are less likely to forget some of
  the requirements.
• Requirement categories for Games?

7

• 5.5 How are Requirements Organised in UP
  Artifacts?
• The UP includes the following optional artifacts
  to record, keep track of and more generally
  manage requirements
• Use Case Model a set of typical scenarios
  (primarily for functional requirements)
• Supplementary Specification basically for
  non-functional requirements
• Glossary a central repository of noteworthy
  terms
• Vision summarises the requirements and the
  business case for the project. Inludes a short
  executive overview
• Business Rules (aka Domain Rules) external
  constraints that the project will have to
  respect, e.g. Banking procedures, network
  protocols, safety critical software regulations
• To this I would add
• Prototypes
• Existing applications
• The format for these documents is pretty free
  but templates do exist and software companies may
  impose their own version

8

• 5.6 Conclusion
• Since software requirements are hard to capture
  and do change over time an evolutionary approach
  to requirements gathering is more suitable than a
  big-bang, waterfall, approach.
• However this does not imply sloppyness during
  their analysis, documentation and change
  management.
• Questions Please