Software Engineering PPT
-
Upload
priyank-kumar -
Category
Documents
-
view
64 -
download
2
Transcript of Software Engineering PPT
Software Engineering
IT350
Lecture 3
Software Process Models and
Process Iteration
Software Requirements
Summary of last session
• Difference between Software Engineering and
Computer Science
2Software Engineering
Summary of last session
• Difference between Software and System
Engineering
• Software Process
• Software Process model
• CASE tools
• Attributes of good software
Software Engineering 3
Summary of last session
• Characteristics of an activity in a process
Software Engineering 4
Summary of last session
• Software Process Models
– Waterfall model
– Evolutionary development
– Formal Systems Development Model
– Reuse-Oriented development
Software Engineering 5
Agenda
• Software Process Models
– Waterfall model
– Evolutionary development
– Formal Systems Development Model
– Reuse-Oriented development
• Process iteration
• Software Requirements
6Software Engineering
Formal Systems Development Model
Software Engineering 7
Requirementsdefinition
Formalspecification
Formaltransformation
Integration andsystem 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 large-
scale systems.
8Software Engineering
Reuse-Oriented development
9Software Engineering
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.
10Software Engineering
Process Iteration
• Where parts of the process are repeated as
system requirements evolve.
• Types of iterative processes:
– Incremental development
– Spiral development
Software Engineering 11
Incremental development
Software Engineering 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
Software Engineering 13
Disadvantages
• Communication overhead
• Difficult to freeze requirements
• Requires a very efficient change control
mechanism
Software Engineering 14
Spiral Model
Software Engineering 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
Software Engineering 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.
Software Engineering 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
Software Engineering 18
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 system’s functions, services and operational constraints.
– Defines what should be implemented so may be part of a contract between client and contractor.
Software Engineering 19
• 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.
Software Engineering 20
Readers of different specification
type
Software Engineering 21
User requirements
Client managersSystem end-usersClient engineersContractor managersSystem architects
System requirements
Software devlopersSystem end-usersClient engineersSystem architects
Software design specification
Client engineersSystem architectsSoftware developers
Level of detail
Software Engineering 22
User requirement
System requirement
Software design specification
Software Engineering 23
Software Engineering 24
THANK YOU!!!
25Software Engineering
Software Engineering
IT350
Lecture 4
Software Requirements
Summary of last session
• Software Process Models
– Waterfall model
– Evolutionary development
– Formal Systems Development Model
– Reuse-Oriented development
• Process iteration
– Incremental model
– Spiral model
2Software Engineering
Agenda
• What is a requirement?
• What is requirement engineering?
• Different types of requirements
Software Engineering 3
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.
Software Engineering 4
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
Software Engineering 5
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 system’s functions, services and operational constraints.
– Defines what should be implemented so may be part of a contract between client and contractor.
Software Engineering 6
• 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.
Software Engineering 7
Readers of different specification
type
Software Engineering 8
User requirements
Client managersSystem end-usersClient engineersContractor managersSystem architects
System requirements
Software devlopersSystem end-usersClient engineersSystem architects
Software design specification
Client engineersSystem architectsSoftware developers
Level of detail
Software Engineering 9
User requirement
System requirement
Software design specification
Software Engineering 10
Software Engineering 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.
Software Engineering 12
Software Engineering 13
Software Engineering 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
Software Engineering 15
Non-functional requirements
Product requirements Organisational requirements External requirements
Product behaviour Based on policies and
procedures
• customer’s organisation
•developer’s organisation
Factors external to the
system
•Usability
•Performance
•Space
•Reliability
•Portability
•Delivery
•Implementation
•Standards
•Interoperability
•Ethical
•Safety
•Privacy
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
Eg 1: The product must follow
ISO standards
Eg 2: It should be developed
using Java language
Eg 1: Only the team lead
has
program check-out/check-
in authority.
Eg 2: Payments are
uploaded to the
frame:ABC123 at 3:00am
each Friday.
16Software 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.
Software Engineering 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 account’s permanent storage area.
Software Engineering 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.
Software Engineering 19
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 60601-
1: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
Software Engineering 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.
Software Engineering 21
THANK YOU!!!
22Software Engineering
Software Engineering
IT302
Lecture 5
Software Requirement
& Requirement engineering
processes
Summary of last session
• Functional and Non-functional requirements
• User requirements
• System requirement
• Software design specification
2Software Engineering
Agenda
• User and System requirements continued
• Software requirement document
• Requirement engineering process
• Feasibility study
Software Engineering 3
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.
4Software Engineering
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 beturned 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 gridlines 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.
5Software Engineering
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
6Software Engineering
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.
Software Engineering 7
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
8Software Engineering
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)
9Software Engineering
• Function
• Description
• Inputs
• Source
• Outputs
• Destination
• Requires
• Pre-condition
• Post-condition
• Side-effects
Software Engineering 10
• 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 user’s screen.
• Post-condition The design is unchanged apart from the addition of a node of specified type at the given position.
• Side-effects None
Software Engineering 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
12Software Engineering
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
13Software Engineering
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 sub-system to another sub-system.
– Representation of data which have been established for an existing sub-system.
Software Engineering 14
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.
15Software Engineering
Use the requirements todevelop validation tests forthe system
Use the requirementsdocument to plan a bid forthe system and to plan the
system development process
Use the requirements tounderstand what system is tobe developed
System testengineers
Managers
System engineers
Specify the requirements andread them to check that they
meet their needs. Theyspecify changes to therequirements
System customers
Use the requirements to help
understand the system andthe relationships between itsparts
Systemmaintenance
engineers
16Software Engineering
IEEE standard for SRS
• Introduction– Purpose
– Scope
– Definition, acronyms and abbreviations
– References
– Overview
• General description– Product perspective
– Product functions
– User characteristics
– General constraints
– Assumptions
• Specific requirements– Functional requirements
– Non-functional requirements
– External interface requirements
• Appendices
• Index
17Software Engineering
Deadline 2
• Task:
– SRS in IEEE format
• Plagiarism Control : YES
• Deadline:
– 13 rd Aug, 2012 by 10:00 am
Software Engineering 18
Requirements engineering
Software Engineering 19
Feasibility study
• Feasibility study determines whether proposed
system is wothwhile or not.
• Three activities are involved
– Informatin assessment
– Information collection
– Report writing
Software Engineering 20
• 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?
Software Engineering 21
Information assessment
Information Sources
• Managers of department
• Software Engineers
• Technology experts
• End-users etc
Software Engineering 22
Outcome
– May approve a proposal
– May break the proposal
– May change:
• Project scope
• Budget
• Schedule of the project
Software Engineering 23
THANK YOU!!!
Software Engineering 24
Software Engineering
IT302
Lecture 6
Requirements Engineering
Summary of last session
Software Engineering 2
Summary of last session
• 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
Software Engineering 3
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 ;
Software Engineering 4
Summary of last session
• Disadvantage of PDL
– Not expressive
– Not understood by everyone
– More of design specification
Software Engineering 5
Summary of last session• Interface specification
• Software requirements specification(SRS)
• Introduction– Purpose
– Scope
– Definition, acronyms and abbreviations
– References
– Overview
• General description– Product perspective
– Product functions
– User characteristics
– General constraints
– Assumptions
• Specific requirements– Functional requirements
– Non-functional requirements
– External interface requirements
• Appendices
• Index
Software Engineering 6
Summary of last session
Software Engineering 7
Summary of last session
• Feasibility study : Feasibility study
determines whether proposed system is
wothwhile or not.
Software Engineering 8
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.
Software Engineering 9
• 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 user’s screen.
• Post-condition The design is unchanged apart from the addition of a node of specified type at the given position.
• Side-effects None
Software Engineering 10
Agenda
• Requirement elicitation and analysis
Software Engineering 11
Requirements engineering
Software 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
system’s operational constraints.
• May involve end-users, managers, engineers
involved in maintenance, domain experts, trade
unions, etc. These are called stakeholders.
Software Engineering 13
Stakeholders
• Anyone who has direct or indirect influence on
the system requirements.
• Such as,
– Customer
– End user
– Domain experts etc
Software Engineering 14
Requirements elicitation and
analysis
Process entry
Software Engineering 15
Requirementschecking
Domainunderstanding
Requirements collection
Classification
Conflictresolution
Prioritisation
Requirementschecking
Domainunderstanding
Requirements collection
Classification
Conflictresolution
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.
Software Engineering 16
• Methods for requirement elicitation and
analysis:
– Viewpoint-oriented elicitation
– Scenarios
• Event scenarios
• Use-case
– Ethnography
Software Engineering 17
Thank you!!!
Software Engineering 18