CO2401 Software Development

1
CO2401 Software Development

• Teaching structure
• Lecture
• Labs
• Assessment
• Assignment 50
• Exam 50

2
CO2401 Software Development

• Project Lifecycle
• Requirements
• HCI GUI
• Design
• Code
• Testing
• Quality
• Evaluation

3
Objectives

1. To introduce the idea of system requirements and
   the requirements engineering process for software
   systems
2. To explain how requirements engineering fits into
   a broader system engineering process
3. To explain the importance of the system
   requirements document (SRS)

4
Software systems

• Computer systems fall into two broad categories
• User-configured systems where a purchaser puts
  together a system from existing software products
• Custom systems where a customer produces a set of
  requirements for hardware/software system and a
  contractor delivers that system

5
Software systems (continued)

• Classes of custom systems
• Information systemsPrimarily concerned with
  processing information
• Embedded systemsSystems where software is used
  as a controller in a hardware system (e.g. video
  camera)
• Command and control systemsA combination of
  information systems and embedded systems where
  special purpose computers provide information
  which is collected and stored and used to make
  decisions

6
Terminology

• System requirementsDefine what the system is
  required to do and constraints under which it
  will be required to operate
• Requirements engineeringThe structured set of
  activities involved in developing system
  requirements (are accountable for approx 15 of
  system development costs)
• Requirements documentThe formal statement of
  system requirements
• System stakeholdersAnyone affected by the system
• Requirements managementThe processes involved in
  making changes to requirements

7
Requirements document structure

• IEEE/ANSI 830-1993 standard recommended structure
  for software requirements documents
• 1 Introduction
• 1.1 Purpose of document
• 1.2 Scope of the product
• 1.3 Definitions, acronyms and abbreviations
• 1.4 References
• 1.5 Overview of the remainder of the document

8
Requirements document structure

• 2 General description
• 2.1 Product perspective
• 2.2 Product functions
• 2.3 User characteristics
• 2.4 General constraints
• 2.5 Assumptions and dependencies
• 2.6 Apportioning of requirements
• 3 Specific requirements
• - Covering functional, non-functional and
  interface requirements
• 4 Appendices
• 5 Index

9
Requirements document structure

• 1 Introduction
• 1.1 Purpose
• This sub-section should
• Describe the purpose of the SRS
• Specify the intended audience of the SRS

10
Requirements document structure

• 1 Introduction
• 1.2 Scope
• This sub-section should
• Identify the software product(s) to be produced
  by name
• Explain what the software product(s) will do and
  not do
• Describe the application of the software
  including benefits, objectives and goals
• Be consistent with higher level specifications if
  they exist

11
Requirements document structure

• 1 Introduction
• 1.3 Definitions, acronyms and abbreviations
• This sub-section should
• Provide the definitions of all terms a complete
  list of all terms, acronyms and abbreviations
  required to properly interpret the SRS
• This information may be provided by reference to
  one or more appendixes in the SRS or reference to
  other documents

12
Requirements document structure

• Introduction
• 1.4 References
• This sub-section should
• Provide a complete list of documents referenced
  elsewhere in the SRS
• Identify each document by title, report number
  (if applicable), date and publishing organisation
• Specify the sources from which the references can
  be obtained

13
Requirements document structure

• Introduction
• 1.5 Overview
• This sub-section should
• Describe what the rest of the SRS should contain
• Explain how the SRS is organised

14
Requirements document structure

• 2 General description
• 2.1 Product perspective
• 2.2 Product functions
• 2.3 User characteristics
• 2.4 General constraints
• 2.5 Assumptions and dependencies
• 2.6 Apportioning of requirements
• 3 Specific requirements
• - Covering functional, non-functional and
  interface requirements
• 4 Appendices
• 5 Index

15
Requirements document structure

• General description
• 2.1 Product perspective
• This sub-section should
• Put the product in perspective with other related
  products
• If the product is totally self-contained it
  should be stated here.
• If the product is a component of a larger system,
  functionality of the software to the requirements
  of the larger system should be stated and
  interfaces between the two systems should be
  stated. Block diagrams may be useful for showing
  components and interfaces of two systems.

16
Requirements document structure

• General description
• 2.1 Product perspective (continued)
• This sub-section should also describe how the
  software operates inside various constraints.
  For example, these could include
• System interfaces
• User interfaces
• Hardware interfaces
• Software interfaces
• Communication interfaces
• Memory
• Operations
• Site adaptation requirements

17
Requirements document structure

• General description
• 2.2 Product functions
• This sub-section provides a summary of the major
  functions that the software will perform. For
  example, and SRS for an accounting program may
  use this part to address customer account
  maintenance, customer statement and invoice
  preparation.
• For the sake of clarity
• The functions should be organised in a way that
  makes them understandable to anyone reading the
  document
• Textual or graphical methods can be used to show
  the functions and their relationships. Such a
  diagram is not intended to show a design of the
  product, but simply shows the logical
  relationships among variables.

18
Requirements document structure

• General description
• 2.3 Constraints
• This sub-section should provide a general
  description of any other items that will limit
  the developers options. These include
• Regulatory policies
• Hardware limitations
• Interfaces to other applications
• Reliability requirements
• Criticality of the application
• Safety and security considerations

19
Requirements document structure

• General description
• 2.4 Assumptions and dependencies
• This sub-section should list each of the factors
  that affect the requirements stated in the
  SRS.provide a general description of any other
  items that will limit the developers options.
  These include
• Regulatory policies
• Hardware limitations
• Interfaces to other applications
• Reliability requirements
• Criticality of the application
• Safety and security considerations

20
Requirements document structure

• General description
• 2.5 Apportioning of requirements
• This sub-section should identify requirements
  that may be delayed until future versions of the
  system

21
Requirements document structure

• Specific requirements
• This section of the SRS should contain all the
  software requirements to a level of detail
  sufficient to enable designers to design a system
  to satisfy those requirements, and testers to
  test that the system satisfies those
  requirements.

22
Requirements document structure

• Specific requirements (continued)These
  requirements should include at a minimum a
  description of every input (stimulus) into the
  system, every output (response) from the system,
  and all functions performed by the system in
  response to an input or in support of an output.

23
Requirements document structure

• Specific requirementsAs this is often the
  largest and most important part of the SRS, the
  following principles apply
• Specific requirements should be stated in
  conformance with all the characteristics
  described in the section titled Characteristics
  of a good SRS
• Specific requirements should be cross-referenced
  to earlier documents that relate
• All requirements should be uniquely identifiable
• Careful attention should be given to organising
  the requirements to maximise readability

24
Requirements document structure

• Specific requirementsThe items that compromise
  requirements are
• 3.1 External interfaces
• 3.2 Functions
• 3.3 Performance requirements
• 3.4 Logical database requirements
• 3.5 Design constraints
• 3.6 Software system attributes
• 3.7 Organising the specific requirements

25
Requirements document structure

• Specific requirements3.1 External interfaces
• This part should contain a detailed description
  of all inputs into and outputs from the software
  system.
• It should complement the interface descriptions
  from section 2 of the document and should not
  repeat the information from there

26
Requirements document structure

• Specific requirements 3.1 External interfaces
  (continued)
• This part should include both content and format
  as follows
• Name of item
• Description of purpose
• Source of input or destination of output
• Valid range, accuracy and/or tolerance
• Units of measure
• Timing

27
Requirements document structure

• Specific requirements 3.1 External interfaces
  (continued)
• Relationships to other inputs/outputs
• Screen formats/organisation
• Window formats/organisation
• Data formats
• Command formats
• End messages

28
Requirements document structure

• Specific requirements 3.2 Functions
• Functional requirements should define the
  fundamental actions that must take place in the
  software in accepting and processing the inputs
  and and in processing and generating the outputs.
• Functional requirements are generally listed as
  shall statements starting with The system
  shall

29
Requirements document structure

• Specific requirements 3.2 Functions (continued)
• Functional requirements include
• Validity checks on the inputs
• Exact sequence of operations
• Responses to abnormal situations (e.g., overflow,
  communication facilities, error handling and
  recovery)
• Effect of parameters
• Relationship of inputs to outputs, including
• Input/output sequences
• Formulas for input to output conversion

30
Requirements document structure

• Specific requirements 3.3 Performance
  requirements
• This subsection should specify both the static
  and dynamic numerical requirements placed on the
  software or on the human interaction with the
  software as a whole.
• Static numerical requirements are sometimes
  identified under a separate section titled
  Capacity

31
Requirements document structure

• Specific requirements 3.3 Performance
  requirements (continued)
• Static numerical requirements may include the
  following
• The number of terminals to be supported
• The number of simultaneous users to be supported
• Amount and type of information to be handled

32
Requirements document structure

• Specific requirements 3.3 Performance
  requirements (continued)
• Dynamic numerical requirements may include the
  following
• The numbers of transactions and tasks
• The amount of data to be processed within certain
  time periods for both normal and peak workload
  conditions

33
Requirements document structure

• Specific requirements 3.3 Performance
  requirements (continued)All performance
  requirements should be stated in measurable
  terms
• For example
• 95 of the transactions shall be processed in
  less than one second
• Rather than
• An operator shall not have to wait for the
  transaction to complete
• Note Numerical limits applied to one specific
  function are normally specified as part of the
  processing subparagraph description of that
  function

34
Requirements document structure

• Specific requirements 3.4 Logical database
  requirements
• This part should specify the logical
  requirements for any information that is to be
  placed in a database. This may include the
  following
• Types of information used by various functions
• Frequency of use
• Accessing capabilities
• Data entities and their relationships
• Integrity constraints
• Data retention requirements

35
Requirements document structure

• Specific requirements 3.5 Design constraints
• This part should specify design constraints that
  can be imposed by other standards, hardware
  limitations etc
• 3.5.1 Standards compliance
• The standards section should specify the
  requirements derived from existing standards or
  regulations. They may include the following
• Report format
• Data naming
• Accounting procedures
• Audit tracing
• e.g. this could specify a requirement for
  software to trace processing activity

36
Requirements document structure

• Specific requirements 3.6 Software system
  attributes
• There are a number of attributes of software
  that can serve as requirements. It is important
  that required attributes can be specified so that
  their achievement can be verified. The following
  is a partial list of examples
• 3.6.1 Reliability
• 3.6.2 Availability
• 3.6.3 Security
• 3.6.4 Maintainability
• 3.6.5 Portability

37
Requirements document structure

• Specific requirements 3.6 Software system
  attributes
• 3.6.1 Reliability
• Should specify the factors required to establish
  the required reliability of the software system
  at the time of delivery
• 3.6.2 Availability
• Should specify the factors required to guarantee
  a defined availability level for the entire
  system such as checkpoint, recovery and restart

38
Requirements document structure

• Specific requirements 3.6 Software system
  attributes
• 3.6.3 Security
• Should specify the factors that protect the
  software from accidental or malicious access,
  use, modification, destruction, or disclosure.
  Specific requirements in this area could include
  the need to
• Utilise certain cryptographical techniques
• Keep specific log or history data sets
• Assign certain functions to different modules
• Restrict communications between some areas of the
  program
• Check data integrity for critical variables

39
Requirements document structure

• Specific requirements 3.6 Software system
  attributes
• 3.6.4 Maintainability
• Should specify attributes of software that
  relate to the ease of maintenance of the software
  itself. There may be some requirement for
  certain modularity, interfaces, complexity etc
• Note Requirements should not be placed her
  because just because they are thought to be good
  design practises

40
Requirements document structure

• Specific requirements 3.6 Software system
  attributes
• 3.6.5 Portability
• Should specify attributes of software that
  relate to the ease of porting the software to
  other host machines and/or operating systems.
  This may include the following
• Percentage of components with host dependant code
• Percentage of code that is host dependant
• Use of a proven portable language
• Use of a particular compiler or language subset
• Use of a particular operating system

41
Requirements document structure

• Specific requirements 3.6 Software system
  attributes
• 3.6.5 Portability
• Should specify attributes of software that
  relate to the ease of porting the software to
  other host machines and/or operating systems.
  This may include the following
• Percentage of components with host dependant code
• Percentage of code that is host dependant
• Use of a proven portable language
• Use of a particular compiler or language subset
• Use of a particular operating system

42
Requirements document structure

• Specific requirements 3.7 Organising the
  specific requirements
• For anything but trivial systems the detailed
  requirements tend to be extensive. For this
  reason, it is recommended that careful
  consideration is given to organising these in
  manner optimal to understanding. There is no one
  optimal organisational for all systems.
  Different classes of systems lend themselves to
  different organisations of requirements in
  section 3 of the SRS.