REQUIREMENT SPECIFICATION

1
REQUIREMENT SPECIFICATION

• Today Requirements Specification
• Requirements tell us what the system should do -
  not how it should do it.
• Requirements are independent of the
  implementation tools, programming paradigm, etc.
• However, the requirements are then analysed with
  the intended implementation methodology in mind.

2
Requirement specification motivation and basics

• Requirement specification is generally a crucial
  phase of an average software project - if it
  succeeds then a complete failure is unlikely.
• The requirements specification can be used as a
  basis for a contract.
• The requirements specification can (and should)
  also be eventually used to evaluate if the
  software fulfills the requirements.
• As users generally can not work with formal
  specifications, natural language specifications
  must or should often be used.

3
Typical Documents

• Basic textual document, e.g. according to the
  ANSI/IEEE Standard 830 will be discussed later.
• A conceptual model of the domain, which may be
  already available or built separately.
• A description of the processes, e.g. a data flow
  diagram.
• A textual description of the use cases will be
  discussed later.

4
Formal Languages?

• Usually much too difficult to understand even for
  an above average user.
• You may be able to verify the system, but how can
  you verify the requirements?
• They are usually used for critical well-defined
  systems and/or concurrent processing, which is
  notoriously difficult to handle.

5
Graphical Languages?

• Examples
• - Entity-Relationship (ER) model for conceptual
  description- Data Flow diagrams for process
  description
• - These are, however, often more suitable for
  analysis and
• design tasks.
• Simple languages (like the above) work well in
  practice
• In requirement specification, they should be used
  to model the application domain and the
  processes.
• If a domain conceptual model exists, it should be
  used to accompany the requirements.

6
Good Requirements Specification Qualities

• Complete
• Accurate
• Unambiguous
• Verifiable (How can you verify user
  friendliness?)
• Consistent
• Modifiable (also the requirements change)
• Traceable (where has each requirement come from?)

7
Ansi/IEEE Standard 830

• 1. Introduction 1.1. Purpose 1.2. Scope
  1.3. Definitions, Acronyms and Abbreviations
  1.4. References 1.5. Overview2. General
  Description 2.1. Product Perspective 2.2.
  Product Functions 2.3. User Characteristics
  2.4. General Constraints 2.5. Assumptions and
  Dependencies3. Specific Requirements

8
ANSI/IEEE Specific requirements

• 3. Specific requirements 3.1. Functional
  Requirements 3.2. External Interface
  Requirements 3.3. Performance Requirements
  3.4 Design Constraints 3.4.1. Standards
  Compliance 3.4.2. Hardware Limitations
  3.5. Attributes 3.5.1. Security 3.5.2.
  Maintainability 3.6. Other Requirements
  3.6.1. Data Base

9
ANSI/IEEE Specific requirements

• 3. Specific requirements 3.1. Functional
  Requirements 3.2. External Interface
  Requirements 3.3. Performance Requirements
  3.4 Design Constraints 3.4.1. Standards
  Compliance 3.4.2. Hardware Limitations
  3.5. Attributes 3.5.1. Security 3.5.2.
  Maintainability 3.6. Other Requirements
  3.6.1. Data Base
• 4. Extensions (acceptance criteria, other
  material...)

10
ANSI/IEEE Functional Requirements

• 3.1. Functional Requirements 3.1.1. Functional
  Requirement 1 3.1.1.1 Introduction
  3.1.1.2 Inputs 3.1.1.3 Processing 3.1.1.4
  Outputs 3.1.2 Functional Requirement 2
  3.1.n Functional Requirement n
• A typical way to express the requirements is The
  system shall Järjestelmän on ...
• Use cases (coming later) describe functionalities

11
An Alternative Template

• Go to Pressmans books web pages
  (http//www.pressman5.com) and from their choose
  professional resources and then
  http//www.rspa.com and from there you can find
  work product templates. The one we are looking
  for is called System specification.
• Ok, you can go to rspa pages directly as well,
  but it may be a good idea to check up pressmans
  pages as well.

12
Techniques For Getting The Requirements From Users

• Asking- Interview- Questionnaire-
  Brainstorming sessions
• Analysing an existing system- We must understand
  how the new system will differ from any old
  such system
• Analysing the environment- e.g. process analysis
• Prototyping- Gives best feedback and more formal
  specifications but can be expensive

13
What can go wrong? / 1

• Missing specifications- Happens often-
  Experience helps- Sometimes it is impossible to
  notice
• Contradictions- Do not document the same thing
  many times- Integrate different users views
  with the users- Sometimes the users disagree
  strongly.
• Noise- Do not include material which does not
  contain relevant information

14
What can go wrong? / 2

• Documenting a solution rather than the problem-
  If the users know some information technology,
  they want to start solving the problem as they
  express it.- Many formal (also graphical)
  methods tend to direct the process into this.
• Unrealistic requirements- Although we model the
  problem rather than the solution, it is good
  to have some idea of what is possible.

15
Who should do requirement specification?

• Someone who can communicate with the users
• Someone who has experience
• Someone who knows similar systems and/or the
  application area
• Someone who knows what is possible and how (and
  how much work is roughly needed).