The Trouble with Requirements

1
The Trouble with Requirements

• From
• Use Cases Requirements in Context Second
  Edition
• RUP Chapter 9 The Requirements Discipline

2
Traditional Activities

• Typical development activities include
• business modeling
• requirements gathering,
• analysis and design,
• construction,
• testing,
• deployment and
• maintenance.
• Frequently given lip service
• Business modeling
• Requirements gathering
• Testing
• Deployment
• Maintenance

3
Landscape of Requirements

• Perception changing from only emphasizing big
  three
• Analysis, design, and construction
• Realization of criticality of requirements!!
• More projects fail due to poor requirements
  specification and poor requirements management
  than for any other reasons.
• Requirements are difficult to capture
• Maybe from drawing, org charts, pure text
• Dont translate nicely into pure modules that
  programmers know and love.
• Difficult for programmers (dealing with the
  concrete) to comprehend abstractions of
  requirements.

4
Landscape of Requirements

• We dont like to spend lots of time here
• Takes too long
• We like to plod on (often operating under false
  assumptions).
• In fairness
• Huge volumes of requirements (lists) (Tab 1.1)
• Horribly boring
• Difficult to discern critical needs from desires.
• Requirements may sometimes be dictated by a
  single person (depending on size of application,
  this may not be good! You will get that
  persons views and biases.
• Analysis paralysis

5
Goals of Requirements Discipline

• To establish and maintain agreement with the
  customers and other stakeholders on what the
  system should do and why.
• To provide system-developers with a better
  understanding of the system requirements
• To define the boundaries (delimit) of the system
• To provide a basis for planning the technical
  contents of iterations
• To provide a basis for estimating cost and time
  to develop the system (RUP Chap 9)
• So, what kind of requirements do we have???

6
Functional and Non-Functional Requirements

• Functional requirements are what the users need
  for the system to work.
• Normally we think about those things that the
  system does on behalf of the user.
• Need to add, change and delete transactions
• Need to generate this report and that
  report
• System must be able to do these things.
• Non-functional requirements (Quality attributes)
• Items like performance, scalability, usability,
  supportability, reliability, security,
  backup/recovery
• Normally documented as Supplementary
  Specifications
• Vitally important (sometimes hidden) global

7
Functional Requirements

• Merely something that the computer application
  does for its users. A value or feature!
• Functional requirements are used to express the
  behavior of a system by specifying both the input
  and output conditions that are expected to
  result.
• Sum of requirements gt scope of application
• Add requirements? Scope increases
• Scope creep!
• Document system functions in the users language
  and from users perspective!
• Requirements indicate specific system responses
  to user inputs (interactions).

8
Non-Functional Requirements

• Non-functional quality attributes of system.
• Usability
• Human factors aestethics, ease of use,
  learning consistency in the user interface
  training,
• Reliability
• Addresses the frequency and severity of failure
  recoverability, MTBF, MTTR, etc.
• Performance
• Transaction rates/speeds, availability, response
  time, recovery time
• Supportability
• Testability, maintainability,
• Not tied (normally) to specific functions but
  vital!

9
Requirements

• Functional Requirements documents user functions
  and application features needed by user
  (typically end-user especially. But there are
  lots of stakeholders!)
• Essential to understand (document/capture/model)
  stakeholder needs!
• Need to solicit and capture needs from VARIOUS
  stakeholders!
• Sometimes needs are abstractions of the real
  problems behaviors are described. Often not
  very clear.
• Clear functionality is easier to deal with and
  can be documented/managed using (ahead) Use Cases
• Non-functional requirements however, normally
  transcend / thread use cases and are often
  captured in Supplementary Specifications.
• Together the functionality (via Use Cases) and
  non-functional, quality attributes (via the
  Supplementary Specifications) constitute the
  total requirements of the system.

10
Software Requirements Specifications (SRS)

• Given inputs from Stakeholder requests, we
  develop a Vision Statement
• contains key stakeholder needs and high-level
  features
• Recognize that this vision statement contains
  features with related costs and anticipated ROI.
  
• Map these desired, high-level features into
  software requirements from which the system can
  be developed.
• Thus develop a Software Requirements
  Specification (SRS).
• SRS consists of
• Detailed requirements via Use Case Models and Use
  Cases (functional specs)
• Requirements that dont fit in well with Use
  Cases are captured in the Supplementary Specs
  (non-functional specs)
• The SRS feeds / supports follow on design
  testing, and a host of other activities (see fig
  9-1 in RUP)

11
Heuristics (an aside comment)

• Requirements are the WHATs of an application.
• Desired functional and non-functional features.
• Design is the HOWs of an application.
• specific classes will be used.
• database / file system
• Heavily architecturally-oriented artifacts,
  layers
• platforms, middleware, programming language,
  networking approach, etc.
• Again, HOW do we, as developers, satisfy the
  Whats of the system?

12
Requirements and Design

• VERY different activities
• Require different mindsets different people and
  skill sets.
• Requirements understanding the problem at hand
• Design solving the problem
• Clearly, cannot design a solution until the
  problem has been identified, documented and
  understood!

13
Requirements Artifacts

• Inputs
• Business Models (Business Use Case Business
  Object Models Domain Model)
• Stakeholder requests (customers, users, product
  managers, developers, etc.) plus how requests
  were considered.
• Artifacts SRS
• Vision Document (not always included here)
• Use Case Model (Use Case Diagrams and Use Case
  Narratives)
• Supplementary Specifications

14
Vision Document

• Complete vision of software under development
• Basis for funding authority and development
  organization.
• Written from Customers perspective focusing on
  essential features and quality.
• Includes what will be included
• Specifies operations characteristics
• Volumes, response times, user profiles,
  interfaces with other systems.
• Is the Contractual basis for the requirements
  visible to the stakeholders.

15
Use Case Model

• Concentrates on the functionality of system
• Can serve as a contract among the customer,
  users, and developers
• Consists of Use Case Diagrams, Use Cases, and
  Actors
• Use Cases serve as the unifying thread throughout
  the software lifecycle and drives analysis,
  design, implementation and testing.

16
Supplementary Specs

• Normally a text document citing the alities
  required, such as
• Usability
• Reliability
• Etc. etc.
• May also include
• Glossary (from Domain Analysis) - extended
• Domain Model (from Domain Analysis) extended /
  modified
• Storyboards (serve as basis for User Interface
  Prototypes) developed from Use Cases.
• Typically developed in parallel with other
  requirements activities.

17
Challenges of Requirement Gathering

• Some state Users do NOT know what they want.
• Sometimes this is very true sometimes NOT.
• Users have lots on their minds besides your
  application!!
• Sometimes users wont commit to written
  requirements
• Communication with users is often very low.
• Conflicts in performing todays job and in
  shaping a new system resistance to change.
• Requirements change dynamicallythe more seen
  the more wanted!
• Remember it is the users who must be satisfied!
• Real problems we need to recognize the
  conflicts users have between their daily jobs and
  how you need that same time to help shape the
  developing system.
• Best approach is to work so very hard at
  establishing personal relationships with users!
  So very essential!

18
What to do?

• Understand the Users divided attentions
• Establish a relationship with your users (again)
• Make it personal
• They will make more meetings, reviews, and answer
  more questions
• Make project more visible
• Escalate the importance of system to senior level
  executives, if possible
• If seniors are aware, more likely users will
  attend requirement sessions, interview sessions,
  etc.
• Be respectful of others time!
• Batch questions, interviews together

19
More on Requirements Gathering and Specification

• Have reviews to avoid conflict
• Try to avoid conflicting requirements
• The larger the volume, the less likely project
  will succeed.
• Establish requirements traceability!!
• Requirements should be traceable throughout the
  effort back to the requirements specification.

20
Requirements Traceability

• Questions that should be answerable
• Analyst/designer Where did this requirement
  come from? Within a class, what requirement does
  this method satisfy? Where is it specified?
• Developer What specific requirements does the
  class youre programming relate to? Executing
  this method satisfies what requirement(s)?
• Many more details on class contents (parameters)
• Heavily architecture-dependent Oftentimes
  multiple components are needed to satisfy
  individual requirements.
• Tester When you execute this test case, what
  exact requirement / requirements are you testing
  for? Can you find it in the requirements
  specification?

21
Standard Approaches (1 of 4)

• User Interviews
• Trying to learn how users do their jobs now, how
  they expect their jobs to change, and typical
  problems they encounter now.
• Interview different people at different levels
  note biases / conflict
• We get their perspective
• Customer, end-user, client, etc
• User Questionnaires
• lots of pros/cons. Many types and ways to
  administer Lots of philosophies on creating
  types of questions open-ended, closed, etc.,
  and methods to evaluate the responses (if any)
• Web pages org chart mission services
• Annual Reports whats going on? Marketing
• Newsletters See local happenings sometimes
  more global

22
Standard Approaches (2 of 4)

• ? Joint Requirements Planning Sessions (JRPS)
• Conduct all interviews at same time in same room.
• All key people brought together.
• Have facilitator, scribe, projectors, and support
  software
• Focus is on WHAT the system
• Have representatives of all key stakeholders
• High-level topics (in JRP) are first critical
  success factors, strategic opportunities, vision,
  risks, business rules,
• Functional/non-functional requirements
  identified, documented, and prioritized. ?
  OWNERSHIP!!
• Normally conducted off-site.
• Artifact the document produced a list of
  requirements. (List? Ech!)

23
Standard Approaches (3 of 4)

• Requirements Lists
• Problems with Requirements Lists
• Most people detest requirement lists!
• Replace with Use Cases, Use Case diagrams, and
  business rules replace the requirements lists.
  (Coming!)
• But not always Requirements lists are sometimes
  used at very early stages for stakeholders and
  clearly differentiating sub-requirements
  (alternatives, exceptions, )
• Review sample requirements lists pp. 17-19.

24
Standard Approaches (4 of 4)

• Prototypes
• Pros
• Very popular in mid 1980s
• Are mock-ups of screens and/or windows
• Primarily used do define user interfaces which
  means functionality!!!
• Great user-interface prototyping tools available
  e.g. VB is super for UI capture.
• Extremely conducive to communications between
  user groups and developers.
• Early changes to screens set stage for fewer
  changes later and reduced overall costs!
• Greatly facilitates stakeholder acceptance later

25
Standard Approaches (4 of 4)

• Prototypes
• Cons
• But, some pay more attention to screen than to
  functionality.
• Executives sometimes fail to realize that
  prototype is not a working system.
• Want it right away
• A throwaway Get buy-in up front on the
  throw-away unless the development strategy
  (small systems) is to hone the prototype into a
  compliant application).
• Prototypes imply more is done than is done.
• Only represent front end (presentation) and do
  not usually represent the business rules.
• At best (but very good!) a great way to determine
  the user interface specification.

26

• Most popular way to capture functional
  requirements is the Use Case a widely-adhered
  to technology.
• Enter Use Cases