co2401 software development teaching structure –lecture –labs assessment –assignment 50%...

CO2401 Software Development• Teaching structure

– Lecture– Labs

• Assessment – Assignment 50%– Exam 50%

CO2401 Software Development

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

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)

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

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

Terminology• System requirements

Define 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

Requirements document structure

IEEE/ANSI 830-1993 standard recommended structure for software requirements documents

1 Introduction1.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

Requirements document structure2 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


1 Introduction

1.1 Purpose

This sub-section should

– Describe the purpose of the SRS

– Specify the intended audience of the SRS


1 Introduction

1.2 Scope


– 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


1 Introduction

1.3 Definitions, acronyms and abbreviations


– 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


1. Introduction

1.4 References


– 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


1. Introduction

1.5 Overview


– Describe what the rest of the SRS should contain

– Explain how the SRS is organised


2 General description2.1 Product perspective2.2 Product functions2.3 User characteristics2.4 General constraints2.5 Assumptions and dependencies2.6 Apportioning of requirements

3 Specific requirements- Covering functional, non-functional and interface requirements

4 Appendices5 Index


2. General description

2.1 Product perspective


• 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.


2. General description2.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

Requirements document structure2. General description

2.2 Product functionsThis 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.



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


2. General description2.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



2.5 Apportioning of requirements

This sub-section should identify requirements that may be delayed until future versions of the system


3. 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.


3. 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.


3. Specific requirements

As this is often the largest and most important part of the SRS, the following principles apply:

a) Specific requirements should be stated in conformance with all the characteristics described in the section titled “Characteristics of a good SRS”

b) Specific requirements should be cross-referenced to earlier documents that relate

c) All requirements should be uniquely identifiable d) Careful attention should be given to organising the requirements

to maximise readability


3. 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


3. 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


3. Specific requirements 3.1 External interfaces (continued)This part should include both content and format as follows:

a) Name of item

b) Description of purpose

c) Source of input or destination of output

d) Valid range, accuracy and/or tolerance

e) Units of measure

f) Timing


3. Specific requirements 3.1 External interfaces (continued)

g) Relationships to other inputs/outputs

h) Screen formats/organisation

i) Window formats/organisation

j) Data formats

k) Command formats

l) End messages


3. Specific requirements 3.2 FunctionsFunctional 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…”


3. Specific requirements 3.2 Functions (continued)

Functional requirements include:a) Validity checks on the inputs b) Exact sequence of operationsc) Responses to abnormal situations (e.g., overflow,

communication facilities, error handling and recovery)d) Effect of parameterse) Relationship of inputs to outputs, including

i. Input/output sequencesii. Formulas for input to output conversion


3. Specific requirements 3.3 Performance requirementsThis 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”


3. Specific requirements 3.3 Performance requirements (continued)

Static numerical requirements may include the following:

a) The number of terminals to be supported

b) The number of simultaneous users to be supported

c) Amount and type of information to be handled


3. Specific requirements 3.3 Performance requirements (continued)

Dynamic numerical requirements may include the following:

a) The numbers of transactions and tasks

b) The amount of data to be processed within certain time periods for both normal and peak workload conditions


3. 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


3. Specific requirements 3.4 Logical database requirementsThis part should specify the logical requirements for any information that is to be placed in a database. This may include the following:

a) Types of information used by various functions b) Frequency of usec) Accessing capabilitiesd) Data entities and their relationshipse) Integrity constraintsf) Data retention requirements


3. Specific requirements 3.5 Design constraintsThis part should specify design constraints that can be imposed by other standards, hardware limitations etc

3.5.1 Standards complianceThe standards section should specify the requirements derived from existing standards or regulations. They may include the following:

a) Report formatb) Data namingc) Accounting proceduresd) Audit tracing

e.g. this could specify a requirement for software to trace processing activity


3. Specific requirements 3.6 Software system attributesThere 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


3. 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


3. 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:

a) Utilise certain cryptographical techniquesb) Keep specific log or history data setsc) Assign certain functions to different modulesd) Restrict communications between some areas of the programe) Check data integrity for critical variables


3. 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


3. 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:

a) Percentage of components with host dependant codeb) Percentage of code that is host dependant c) Use of a proven portable languaged) Use of a particular compiler or language subsete) Use of a particular operating system


3. Specific requirements 3.7 Organising the specific requirementsFor 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.

co2401 software development teaching structure –lecture –labs assessment –assignment 50%...

Documents

system slide

developing system requirements

system requirements

idea of system requirements

set of requirements

interface requirements

specific requirements

apportioning of requirements