CS 310 Ch 6: Software Requirements

1
CS 310 Ch 6 Software Requirements

• Requirements engineering establishing the
  services that
• the customer requires from a system and the
  constraints
• under which it operates and is developed
• Requirements descriptions of the system services
  and
• constraints that are generated during
  requirements
• engineering

2
Hypothetical Problem set up a Software
Assistance Center

• What are the requirements?
• are we thinking the whole system or just the
  programming
• Is there any organization to this?
• How would you present this to Dean Miller-Bernal?
• How would you present this to someone who will
  build it?

3
What is a requirement?

• What the system should do, not how
• what maintain student grades
• how store student grades in a MySQL database
  with web front-end
• Range
• a high-level abstract statement of a service or
  of a system constraint
• a detailed mathematical function (how grades are
  calculated)
• Inevitable since requirements may
• be the basis for a bid - therefore open to
  interpretation
• be the basis for the contract - therefore
  detailed
• Both may be called requirements
• Our goal make them as specific as possible

4
Levels of requirement

• User requirements
• statements in natural language plus diagrams of
  the services the system provides and its
  operational constraintswritten for system users
  who dont have detailed technical knowledge
• problems
• lack of clarity precision can make the document
  difficult to read
• requirements confusion functional and
  non-functional mixed-up
• amalgamation several different requirements
  lumped together
• System requirements (more detailed than user
  requirements)
• a structured document setting out detailed
  descriptions of the system services
• may be used as part of the system contract
• serves as a basis for building the system and for
  acceptance testing
• Don't separate these in your project, aim for a
  complete, detailed document

5
User versus system requirement
User requirement definition 1 The system will
allow TAs to enter grades for each student in CS
10x 2 The system will allow students to check
their current grade
System requirements specification 1.1 The system
will store grades for each student enrolled in CS
10x 1.2 These grades will be retained for 5
years 1.3 TAs must logon to enter or change
student grades 1.4 TAs may change grades only in
courses to which they have been granted
permission 1.4 The system will log each change to
a grade 1.5 A student must logon and can see only
grades in courses she is taking 1.6 The system
will log each failed login attempt
Comment I dont make this distinction. A spec
should contain the details.
6
6.1 Functional and non-functional requirements

• Functional
• services the system should provide, how the
  system should react to particular inputs and how
  the system should behave in particular situations
• the system will allow TAs to enter grades for
  each student in CS 10x
• Non-functional
• constraints on the system services such as timing
  constraints, constraints on the development
  process, standards, etc.
• the system will be available 24/7
• Domain
• requirements that come from the application
  domain of the system and reflect characteristics
  of that domain
• e.g. the laws of physics
• e.g. how grades are calculated

7
Non-functional requirements

How the product must behave
8
Examples

• Product requirement
• all communication between the system and the user
  shall be transferred in XML
• Organizational requirement
• the system development process and deliverable
  documents shall conform to the process and
  deliverables defined in
• XYZCo-SP-STAN-05
• External requirement
• the system shall not disclose any personal
  information about customers apart from their name
  and reference number to the operators of the
  system

9
Requirements measures
10
Back to the Software Assistance Center

• How about these?
• it will be staffed by smart people
• they will answer questions
• it will be open a lot
• the room will be nice
• Do email me 5-10 representative functional and
  non functional
• requirements

11
So, how do we write specifications?

• Natural language
• ambiguous
• over-flexible (one can say the same thing may be
  said several ways)
• lack of modularization
• Alternatives -various more formal notations
• structured natural language (my favorite)
• using a standard form
• using a program design language (PDL)

12
Structured NL specification
13
Form-based node specification
14
Sequence diagram of ATM withdrawal
15
PDL interface description
16
6.5 Software requirements document

• The official statement of what the developers
  must build
• Not a design document. As far as possible, it
  describes what the system should do, not how
• what maintain author, title, and price in a
  database
• how store author, title, and price at locations
  x-y
• It should be
• easy to read/change
• the basis for system design
• the basis for system testing
• a reference tool for maintenance (NO)
• forethought about the system life cycle (NO, only
  as requirements)

17
Users of a requirements document
no
18
Guidelines for writing requirements

• Use a standard format for all requirements
• Use language consistently. Use shall for
  mandatory requirements, should for desirable
  requirements
• (I don't believe "desirable" requirements
  belong)
• Avoid computer jargon
• Be concise
• remove extra words
• do not cover a requirement more than once
• Avoid ambiguity

19

• Exercise
• Rewrite the following requirements so that they
  may be
• objectively validated. You may make any
  reasonable
• assumptions about them.
• The software system shall provide acceptable
  performance under maximum load conditions
• The system interface shall use a character set as
  available on the standard terminal
• If the system fails in operation, there should be
  a minimal loss of data
• The software development process used shall
  ensure that all of the required reviews have been
  carried out
• The software will be well-written
• The software must be developed in such a way that
  it can be used by inexperienced users

20
Requirements document structure

• Introduction describe need for the system and
  how it fits with business objectives
• System models define models showing system
  components and relationships
• Functional requirements the services to be
  provided
• Non-functional requirements constraints on the
  system and the development process
• Appendices. e.g.
• glossary define technical terms used
• system hardware platform
• database requirements (as an ER model perhaps)
• This differs somewhat from the text