Software Engineering

Software Engineering IT350
Lecture 3 Software Process Models and Process Iteration Software Requirements
Summary of last session

Difference between Software Engineering and Computer Science
Software Engineering

Difference between Software and System Engineering Software Process Software Process model CASE tools Attributes of good software

Characteristics of an activity in a process

Software Process Models
Waterfall model Evolutionary development Formal Systems Development Model Reuse-Oriented development
Agenda
Process iteration Software Requirements
Formal Systems Development Model
Requirements definition
Formal specification
Formal transformation
Integration and system testing
Formal Systems Development Model

Advantages
Useful when developing systems require strict safety, reliability and security requirements.
Disadvantages
Mathematical notations used for the formal specifications adds to the system development effort and cost making this model impractical Proofs are very long and impractical for largescale systems.
Software Engineering 8
Reuse-Oriented development
Reuse-Oriented development
Advantages
Reduced cost Save time Minimizes the likelihood of errors or bugs
Disadvantages
May lead to compromises in perceived requirements, resulting in a product that does not fully meet the needs of its intended users.
Process Iteration
Where parts of the process are repeated as system requirements evolve. Types of iterative processes:
Incremental development Spiral development
11
Incremental development
12
Advantages
Customer do not have to wait until the entire system is delivered. Lower risk of failure Highest priority services tend to receive the most testing
13
Disadvantages
Communication overhead Difficult to freeze requirements Requires a very efficient change control mechanism
14
Spiral Model
15
Advantages
Most flexible models in place Risk management is one of the in-built features
Disadvantages
Extensive skill is required in evaluating uncertainties or risks Evaluating the risks can shoot up the cost
16
Introduction to Software Requirements

Requirement:Is a description of services and constraints of a system. Requirement Engineering : Is the process of finding out, analysing, documenting and checking the services and constraints of the system.
17
Requirement
It ranges from a
high-level abstract statement - bid for a contract detailed mathematical functional specification contract
Types of requirements:
User requirement System requirement Software Design specification
Types of requirements
User requirements:
Statements in natural language plus diagrams of the services the system provides and its operational constraints written for customers.
System requirements:
A structured document setting out detailed descriptions of the systems functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.
Eg:
User requirement
The software must provide a means of accessing external files created by other tool
System requirement
The user should have a facility to define the type of the external file. Each external file should have an associated tool which can be applied to view the file Each external file must be represented as an icon on the desktop When the user selects an icon representing an external file, the effect must be to apply the pre-defined tool and open the file.
20
Readers of different specification type

User requirements Client managers System end-users Client engineers Contractor managers System architects Software devlopers System end-users Client engineers System architects
System requirements
Software design specification
Client engineers System architects Software developers
21
Level of detail
User requirement
System requirement

23
24
THANK YOU!!!
25

Lecture 4 Software Requirements

Process iteration
Incremental model Spiral model
Agenda
What is a requirement? What is requirement engineering? Different types of requirements
Introduction to Software Requirements

Requirement:Is a description of services and constraints of a system. Requirement Engineering : Is the process of finding out, analysing, documenting and checking the services and constraints of the system.
Requirements classification
First axis: Based on the level of detail of requirements specification
User requirement System requirement Software design specification
Second axis- based on the operation and behaviour of the system

Functional Non-functional
Types of requirements
User requirements:
Statements in natural language plus diagrams of the services the system provides and its operational constraints written for customers.
System requirements:
A structured document setting out detailed descriptions of the systems functions, services and operational constraints. Defines what should be implemented so may be part of a contract between client and contractor.
Eg:
User requirement
The software must provide a means of accessing external files created by other tool
System requirement
The user should have a facility to define the type of the external file. Each external file should have an associated tool which can be applied to view the file Each external file must be represented as an icon on the desktop When the user selects an icon representing an external file, the effect must be to apply the pre-defined tool and open the file.
Readers of different specification type

User requirements Client managers System end-users Client engineers Contractor managers System architects Software devlopers System end-users Client engineers System architects
System requirements
Client engineers System architects Software developers
Level of detail
User requirement
System requirement

10
11
Functional and Non-functional requirements

Functional requirements
Statements of services the system should provide, how the system should react to particular inputs and how the system should behave in particular situation.
Non-functional requirements
Constraints on the services or functions offered by the system such as timing constraints, constraints on the development process, standards, etc.
13
14
Some of the non-functional requirements

Accessibility Avaliability system up time... Capacity memory, database size, number of users ... Efficiency accuracy of processing.... Maintainability mean time to repair..... Performance speed, accuracy of processing... Portability- Platorms it should suport... Privacy degree of confidentality Recoverability- recovery from power, product failure... Response time Reliability- Mean time to recovery... Security Software tools, standards
15
Non-functional requirements Product requirements Product behaviour Organisational requirements Based on policies and procedures customers organisation developers organisation Delivery Implementation Standards External requirements Factors external to the system
Usability Performance Space Reliability Portability Eg1. No more than 2 defects of severity level 1 are to be reported in a calendar month. Eg2: Should accomediate 500 users on the network
Interoperability Ethical Safety Privacy Eg 1: Only the team lead has program check-out/checkin authority. Eg 2: Payments are uploaded to the frame:ABC123 at 3:00am each Friday.
16
Eg 1: The product must follow ISO standards Eg 2: It should be developed using Java language
Software engineering
Library System
A library system that provides a single interface to a number of databases of articles in different libraries. Users can search for download and print these articles for personal study.
17
Examples of functional requirements

The user shall be able to search ither all of the intial set of databases or select a subset from it. The system shall provide appropriate viewers for the users to read documents in the document store. Every order shall be allocated a unique identifier( ORDER_ID) which the user shall be able to copy to the accounts permanent storage area.
18
Examples of non-function requirements

Product requirement: The user interface for Library system shall be implemented as simple HTML without Java applets. Organizational requirements: The system development process and deliverables documents shall conform to the process and deliverables defined in ISO 9001. 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.
Domain requirements
Reflects the characteristics of the domain Both functional and non-functional
Eg:
The requirements for the insulin pump system that delivers insulin on demand include the following domain requirement:
The system safety shall be assured according to standard IEC 606011:Medical Electrical Equipment Part 1:General Requirements for Basic Safety and Essential Performance.
The requirements for an automated train protection system. This system automatically stops a train if it goes through a red signal. This requirement states how the train deceleration is computed by the system
Dtrain=Dcontrol + Dgradient
20
Domain requirement issues

Understandability: Expressed in the language specific to application domain which is not understood by software engineers. Implicitness: Domain specialists may not leave out information because it is obvious.
21
THANK YOU!!!
22
Software Engineering IT302 Lecture 5 Software Requirement & Requirement engineering processes

Functional and Non-functional requirements User requirements System requirement Software design specification
Agenda
User and System requirements continued Software requirement document Requirement engineering process Feasibility study
Problems with natural language

Lack of clarity: Difficult to use it in a precise and unambiguous way. Requirements confusion: Functional requirements, non-functional requirements, system goals and design information are mixed up. Requirements amalgamation: Several requirements may be expressed together.
Wrong way: Grid facilities To assist in the positioning of entities on a diagram, the user may turn on a grid in either centimetres or inches, via an option on the control panel. Initially, the grid is off. The grid may be turned on and off at any time during an editing session and can be toggled between inches and centimetres at any time. A grid option will be provided on the reduce-to-fit view but the number of grid lines shown will be reduced to avoid filling the smaller diagram with grid lines.
Grid requirement mixes different kinds of requirement
Functional requirement (the need for a grid) Non-functional requirement (grid units) Non-functional interface requirement (via control panel)
Initial information given grid is initially off Initial information missing units when turned on.
Right way:
A grid facility shall be provided, where a matrix of horizontal and vertical lines provide a background to the editor window to add objects to a diagram
How to overcome?
Use standard format such as bolding, including rationale. Use language consistency such as shall for mandatory requirments and should for desirable requirements. Use text highlighting for key parts of requirements. Avoid computer jargons.
Structured language specifications

A restricted form of natural language may be used to express requirements Limits the terminology used and may use templates to specify system requirements Advantage:
No ambiguity Imposes a degree of uniformity
Often best supported using a forms-based approach

Form-based specifications
Definition of the function or entity Description of inputs and where they come from Description of outputs and where they go to Indication of other entities required Pre and post conditions (if appropriate) The side effects (if any)
Function Description Inputs Source Outputs Destination Requires Pre-condition Post-condition Side-effects
Function Add node Description Adds a node to an existing design. The user selects the type of node, and its position. When added to the design, the node becomes the current selection. The user shooses the node position by moving the cursor to the area where the node is added Inputs Node type, node position, Design identifier. Source Node type and Node position are imput by user, Design identifier from the database. Outputs Design identifier Destination The design database. The design is commited to the database on completion of the operation. Requires Design graph rooted at input design identifier. Pre-condition The design is open and displayed on the users screen. Post-condition The design is unchanged apart from the addition of a node of specified type at the given position. Side-effects None
11
PDL-based requirements definition

Requirements may be defined operationally using a program descriptive language (PDL)
Most appropriate in two situations
Where an operation is specified as a sequence of actions and the order is important When hardware and software interfaces have to be specified
12
PDL disadvantages
PDL may not be sufficiently expressive to express the system functionality in an understandable way Notation is only understandable to people with programming language knowledge The requirement may be taken as a design specification rather than a model to help understand the system
Interface specification
Specifies how a system should be interfaced with the other systems. Three types iof interface:
Procedural interface: Where existing system offers a range of services which are accessed by calling interface procedures. Data structures which are passed from one subsystem to another sub-system. Representation of data which have been established for an existing sub-system.
Software requirements specification(SRS)

Is the official statement of what is required of the system developers It is NOT a design document. As far as possible, it should be a set of WHAT the system should do rather than HOW it should do it.
15
System customers
Specify the requirements and read them to check that they meet their needs. They specify changes to the requirements Use the requirements document to plan a bid for the system and to plan the system development process
Managers
System engineers
Use the requirements to understand what system is to be developed
System test engineers
Use the requirements to develop validation tests for the system
System maintenance engineers
Use the requirements to help understand the system and the relationships between its parts
IEEE standard for SRS

Introduction
Purpose Scope Definition, acronyms and abbreviations References Overview Product perspective Product functions User characteristics General constraints Assumptions
General description

Specific requirements
Functional requirements Non-functional requirements External interface requirements
Appendices Index
Deadline 2
Task:
SRS in IEEE format
Plagiarism Control : YES Deadline:

13 rd Aug, 2012 by 10:00 am
18
Requirements engineering
19
Feasibility study
Feasibility study determines whether proposed system is wothwhile or not. Three activities are involved
Informatin assessment Information collection Report writing
20
Information assessment
Does the system contribute to the overall objective of the organisation? Is there a demand for the software? Who else is producing similar software? What is needed to make the software? ( Can the system be developed using the current technology that is used by the organisation.) What is the cost and time required for producing a software? (Can it developed within the cost and schedule?) Can the system be integrated with other systems which are in place? What is the likely profit?
Information Sources
Managers of department Software Engineers Technology experts End-users etc
22
Outcome
May approve a proposal May break the proposal May change:
Project scope Budget Schedule of the project
23
THANK YOU!!!
24
Lecture 6 Requirements Engineering

Problems with natural language
Lack of clarity Requirements confusion Requirements amalgamation
How to overcome? Structured language specifications: Restricted form of natural language

No ambiguity Imposes a degree of uniformity Example: Form-based specification
PDL-based requirements definition

sequence of actions and the order is important hardware and software interfaces have to be specified
procedure ATM is PIN: Pin_no ;

Acc_no: Account_number ; Balance: Amount ; Service: Available_services ; Valid_card, Valid_PIN: Boolean ;
begin
loop
Get_card ( Acc_no, PIN, Valid_card) ; if Valid_card then
Validate_PIN (PIN, Valid_PIN) ; if Valid_PIN then Get_account (Acc_no, Balance) ; Get_service (Service) ; while a service is selected loop Deliver_selected_service ; Get_service (Service) ; end loop ; Return_card ; end if ;
end if ;
end loop
end ATM ;

Disadvantage of PDL
Not expressive Not understood by everyone More of design specification

Interface specification Software requirements specification(SRS) Introduction
Purpose Scope Definition, acronyms and abbreviations References Overview Product perspective Product functions User characteristics General constraints Assumptions
General description

Specific requirements
Functional requirements Non-functional requirements External interface requirements
Appendices Index

Feasibility study : Feasibility study determines whether proposed system is wothwhile or not.
Tips for the assignment

Follow only IEEE format of SRS that has been discussed in class Function requirements under the specific requirements are the details versions i.e. system requirements Phrases such as shall, should and may be should be expressed for mandatory, desired and optional requirements respectively.
Function Add node Description Adds a node to an existing design. The user selects the type of node, and its position. When added to the design, the node becomes the current selection. The user shooses the node position by moving the cursor to the area where the node is added Inputs Node type, node position, Design identifier. Source Node type and Node position are imput by user, Design identifier from the database. Outputs Design identifier Destination The design database. The design is commited to the database on completion of the operation. Requires Design graph rooted at input design identifier. Pre-condition The design is open and displayed on the users screen. Post-condition The design is unchanged apart from the addition of a node of specified type at the given position. Side-effects None
Agenda
Requirement elicitation and analysis
11
Requirements engineering
12
Requirements elicitation and analysis

Sometimes called requirements elicitation or requirements discovery. Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the systems operational constraints. May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.
Stakeholders
Anyone who has direct or indirect influence on the system requirements. Such as,
Customer End user Domain experts etc
14
Requirements elicitation and analysis

Process entry
Domain understanding Requirements checking Prioritisation
Requirements collection Classification
Conflict resolution
15
Problems with elicitation and analysis

Stakeholders do not know what they want from system. Users express requirements in their own terms. Different users may have conflicting requirements. Organisational and political factors may influence the system requirements. The requirements change during the analysis process.
Methods for requirement elicitation and analysis:

Viewpoint-oriented elicitation Scenarios
Event scenarios Use-case
Ethnography
17
Thank you!!!
18

Software Engineering

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Software Engineering

Transféré par

Droits d'auteur :

Formats disponibles

Software Engineering IT350

Lecture 3 Software Process Models and Process Iteration Software Requirements

Summary of last session

Summary of last session

Summary of last session

Summary of last session

Process iteration Software Requirements

Formal Systems Development Model

Integration and system testing

Formal Systems Development Model

Introduction to Software Requirements

Readers of different specification type

Software design specification

Client engineers System architects Software developers

Software design specification