SE351 Roadmap - instruct.uwo.cainstruct.uwo.ca/engin-sc/se351a/notes/HG-SE351... · • Software...
Transcript of SE351 Roadmap - instruct.uwo.cainstruct.uwo.ca/engin-sc/se351a/notes/HG-SE351... · • Software...
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 1
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa
SE351a: Software Project & Process ManagementSE351a: Software Project & Process Management
W4.1: Requirements Engineering
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 2
SE351 RoadmapSE351 Roadmap
Introduction to Software Project Management
Project Management
Software Development Life Cycles
Requirements Engineering
• Software Process & Project Metrics
• Software Project Planning
• Project Monitoring & Control
• Risk Management
• Software Quality Assurance
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 2
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 3
The Objective is…The Objective is…
• High quality Product
• Successful Development Process
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 4
Software Project Management Software Project Management MachineMachine
ProcessProcess
PMLCPMLC
SDLCSDLC
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 3
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 5
Scope the Project State the problem or opportunity Establish the project goal Define the project objectives Identify the success criteria List assumptions, risks and obstacles
Develop Detailed PlansIdentify project activities Estimate activity duration Determine resource requirements Construct & analyze project network Prepare the project proposal
Launch the PlanRecruit and organize project team Establish team operating rules Level project resources Schedule work packages Document work packages
Monitor & Control ProgressEstablish progress reporting system Install change control process Define problem escalation process Monitor progress versus plan Revise project plan Project Close-Out
Obtain client acceptance Install project deliverables Complete project documentation Complete post-implementation audit Issue final project report
PMLC…
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 6
SDLC…SDLC…
Retirement
Operations
Requirements/Specifications
VerifySoftware Requirements
Specification
Operations Manual
Integration
Test
Design
Verify
Implementation
Design Document
Software SystemTest
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 4
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 7
Software Process:Software Process:ExampleExample ––Requirements Engineering Requirements Engineering ProcessProcess
Requirements
Requirements Elicitation
Requirements Analysis and Negotiation
Requirements Specification
Requirements Validation & Verification
Requirements Management
Requirements Elicitation
Requirements Analysis and Negotiation
Requirements Specification
Requirements Validation & Verification
Requirements Management
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 8
Notes…Notes…
• ReadingsIan Sommerville, Software Engineering, 7th Edition, 2005, Pearson Education Limited
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 5
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 9
OutlinesOutlines
• Fundamentals of Requirement Engineering
• Functional & Non-Functional Requirements
• Requirements Engineering Process
• Software Requirements SpecificationIEEE 830 SRS Standards
• Characteristics of Good SRS Document
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 10
Requirements EngineeringRequirements Engineering
• The process of finding, analyzing and documentingthe services that the customer requires from a system, and
the constraints under which it operates and is developed
• Requirements should specify what a system should do
and not how it should do it
the "what-versus-how" dilemma
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 6
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 11
ExamplesExamples
• The system shall allow users to search for an item by title, author, or ISBN
• The user interface shall be implemented using a World-Wide Web browser
• The system shall support at least 20 transactions per second
• The system facilities, available to public users, shall be demonstrable in 10 minutes or less
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 12
ExamplesExamples(Cont.)(Cont.)
• All functionalities of screens, buttons, menus, etc., in the user interface,
and how they interact
• All data transformations,
i.e., all computations need to be done by the system
• Throughput (transactions per unit of time)
• Capacity (amount of data, users, processes, etc. handled)
• Security (ability to resist intruders and protect privacy)
• Response times to user operations
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 7
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 13
Why do Requirements Matter?Why do Requirements Matter?
• Represent the first formalization of the desired deliverable
• Provide a basis for size and effort estimates
• Provide a firm foundation for initial design work
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 14
Requirements vs. CostRequirements vs. Cost
• Boehm and Papccio (1988)If it costs $1 to find and fix a requirement-based problem during the requirements definitions, it can cost
o $5 during design
o $10 during coding
o $20 during unit test
o $200 at productionCost to Fix Error
Req. Design Impl. Test Oper.
Phase when Error Detected.
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 8
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 15
Some Stat…Some Stat…
• The later in the lifecycle an error is detected the more expensive to repair54% of errors detected after coding and unit testing
o 45% of these errors were requirements and design errors
• Estimates indicate that 56% of all errors are those of the requirements stage
• Requirements errors are typically non-clericalincorrect facts 49%
omissions 31%
inconsistencies 13%
ambiguities 5%
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 16
Requirements:Requirements:Definition & SpecificationDefinition & Specification
• Requirements definition (User Requirements)A statement in natural language plus diagramsof the services the system provides and its operational constraints
o Written for clients
• Requirements specification (System Requirements)A structured document setting out detailed descriptions of the system services
o Written as a contract between client and contractor
• Software specificationA detailed software description which can serve as a basis for a design or implementation
o Written for developers
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 9
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 17
Requirements AudienceRequirements Audience
Client managersSystem end-usersClient engineersContractor managersSystem architects
System end-usersClient engineersSystem architectsSoftware developers
Client engineers (perhaps)System architectsSoftware developers
Requirementsdefinition
Requirementsspecification
Softwarespecification
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 18
Problems with Natural LanguageProblems with Natural Language
• Natural language relies on the specification readers and writers using the same words for the same concept
• A natural language specification is over-flexible and subject to different interpretation
• Requirements are not partitioned by language structures
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 10
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 19
Natural Language AlternativesNatural Language Alternatives
• Structured natural language
• Graphical notations
• Mathematical specifications
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 20
Functional Requirements usingFunctional Requirements usingStructured LanguageStructured Language
• A limited form of natural language may be used to express requirements
removes some form of ambiguity and flexibility
imposes a degree of uniformity on a specification
• Often best supported using a forms-based approach
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 11
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 21
Definitions and SpecificationsDefinitions and Specifications
1. The software must provide a means of representing and1. accessing external files created by other tools.
1.1 The user should be provided with facilities to define the type of1.2 external files.1.2 Each external file type may have an associated tool which may be1.2 applied to the file.1.3 Each external file type may be represented as a specific icon on1.2 the user’s display.1.4 Facilities should be provided for the icon representing an1.2 external file type to be defined by the user.1.5 When a user selects an icon representing an external file, the1.2 effect of that selection is to apply the tool associated with the type of1.2 the external file to the file represented by the selected icon.
Requirements definition
Requirements specification
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 22
FormForm--based Functional Specificationsbased Functional 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).
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 12
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 23
Example of a FormExample of a Form--based Functional based Functional SpecificationSpecification
ECLIPSE/Workstation/Tools/DE/FS/3.5.1
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 chooses the node position bymoving the cursor to the area where the node is added.
Inputs Node type, Node position, Design identifier.
Source Node type and Node position are input by the user, Design identifier from the database.
Outputs Design identifier.
Destination The design database. The design is committed to the database on completion of theoperation.
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 the specified typeat the given position.
Side-effects None
Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 24
The Requirements DocumentThe Requirements Document
• The requirements document is the official statement of what is required of the system developers.
• Should include both a definition and a specification of requirements.
• It is NOT a design documentAgain, it should set out WHAT the system should do
NOT HOW it should do it
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 13
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 25
The Requirements DocumentThe Requirements Document(Cont.)(Cont.)
RequirementsDefinitions
RequirementsAnalysis
RequirementsSpecifications
Definition of RequirementsDefinition of Requirements
Specifications of Requirements
Specifications of Requirements
System ModelSystem Model
RequirementsDocument
RequirementsDocument
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 26
Classes of RequirementsClasses of Requirements
• Functional Requirements
• Non-functional Requirements
• Domain Requirements
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 14
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 27
Functional RequirementsFunctional Requirements
• Statements of services the system should provide o how the system should react to particular inputs
o how the system should behave in particular situations
• Functional requirements may be high-level statements of what the system should do
but functional requirements should describe the system services in detail
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 28
Functional Requirements:Functional Requirements:ExamplesExamples
• The user shall be able to search either all of the initial set of databases or select a subset from it
• The system shall provide appropriate viewers for the user 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
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 15
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 29
Functional Requirements:Functional Requirements:Major ProblemsMajor Problems
• Imprecision
• Completeness & Consistency
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 30
Functional Requirements:Functional Requirements:ImprecisionImprecision
• Problems arise when requirements are not precisely stated
• Ambiguous requirements may be interpreted in different ways by different people
the term ‘appropriate viewers’
o User intention
– special purpose viewer for each different document type
o Developer interpretation
– provide a text viewer that shows the contents of the document
the term ‘appropriate viewers’
o User intention
– special purpose viewer for each different document type
o Developer interpretation
– provide a text viewer that shows the contents of the document
The system shall provide appropriate viewers for the user to read documents in the document store The system shall provide appropriate viewers for the user to read documents in the document store
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 16
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 31
Functional Requirements:Functional Requirements:Completeness & ConsistencyCompleteness & Consistency• In principle requirements should be both
Completeo They should include descriptions of all facilities required
Consistento There should be no conflicts or contradictions in the descriptions of the
system facilities
In practice, it is almost impossible to produce a complete and consistent requirements document for large scale systemsIn practice, it is almost impossible to produce a complete and consistent requirements document for large scale systems
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 32
NonNon--functional Requirementsfunctional Requirements
• Define system properties and constraints
Properties: reliability, response time and storage requirements, etc.
Constraints: I/O device capability, system representations, etc.
• Non-functional requirements may be more critical than functional requirements,
i.e., if these are not met, the system is useless
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 17
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 33
NonNon--functional Classificationsfunctional Classifications
• Product requirementsSpecify the behavior of the delivered product
o e.g., execution speed, reliability, etc.
• Organizational requirementsRelated to the organizational policies and procedures
o e.g., process standards used, implementation requirements, etc.
• External requirementsRelated to factors external to the system and its development process
o e.g., interoperability requirements, legislative requirements, etc.
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 34
NonNon--functional Requirements:functional Requirements:Some TypesSome Types
Performancerequirements
Spacerequirements
Usabilityrequirements
Efficiencyrequirements
Reliabilityrequirements
Portabilityrequirements
Interoperabilityrequirements
Ethicalrequirements
Legislativerequirements
Implementationrequirements
Standardsrequirements
Deliveryrequirements
Safetyrequirements
Privacyrequirements
Productrequirements
Organizationalrequirements
Externalrequirements
Non-functionalrequirements
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 18
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 35
NonNon--functional:functional:Major ProblemsMajor Problems
• Verifiability
• Measurements
• Interdependency
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 36
NonNon--functional Requirement:functional Requirement:VerifiabilityVerifiability
• A Verifiable non-functional requirementA statement using some measure that can be objectively tested
A system goalThe system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized
A system goalThe system should be easy to use by experienced controllers and should be organized in such a way that user errors are minimized
A verifiable non-functional requirement
Experienced controllers shall be able to use all the system functions after a total of two hours training
After this training, the average number of errors made by experienced usersshall not exceed two per day
A verifiable non-functional requirement
Experienced controllers shall be able to use all the system functions after a total of two hours training
After this training, the average number of errors made by experienced usersshall not exceed two per day
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 19
NonNon--functional Requirement:functional Requirement:MeasuresMeasures ----ExamplesExamples
Property MeasureSpeed Processed transactions/second
User/Event response timeScreen refresh time
Size K BytesNumber of RAM chips
Ease of use Training timeNumber of help frames
Reliability Mean time to failureProbability of unavailabilityRate of failure occurrenceAvailability
Robustness Time to restart after failurePercentage of events causing failureProbability of data corruption on failure
Portability Percentage of target dependent statementsNumber of target systems
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 38
NonNon--functional Requirement:functional Requirement:InterdependencyInterdependency
• Conflicts between different non-functional requirements are common in complex systems
e.g.,
to minimize storage space,
the maximum store should not exceed 4Mbyte for handheld device,
Portable programming language should be used
e.g.,
to minimize storage space,
the maximum store should not exceed 4Mbyte for handheld device,
Portable programming language should be used
Which is the most critical requirement?Which is the most critical requirement?
however, using platform independent language may require more spacehoweverhowever, using platform independent language may require more space
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 20
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 39
Domain RequirementsDomain Requirements
• Constraints related to the application domain of the system and reflect its characteristics
o Design constraints:
o e.g., specific HW/SW or architectures, such as client-server
o Implementation constraints:
o e.g., implementing the product in C++ or using a specific GUI builder
If domain requirements are not satisfied, the system may be unworkable
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 40
Domain Requirements:Domain Requirements:ExampleExample
• Library system domain requirements
There shall be a standard user interface to all databases which shall be based on the Z39.50 standard
Because of copyright restrictions,
some documents must be deleted immediately on arrival.
Depending on the user’s requirements, these documents will either be printed locally on the system server for manually forwarding to the user or routed to a network printer
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 21
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 41
Domain Requirements:Domain Requirements:Major ProblemsMajor Problems
• UnderstandabilityRequirements are expressed in the language of the application domain
which is often not understood by software engineers
• ImplicitnessDomain specialists understand the area so well
that they do not explicitly define the domain requirements
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 42
Classes of RequirementsClasses of Requirements(Recap)(Recap)
Functional Requirements
Non-functional Requirements
Domain Requirements
Hamada Ghenniwa 10/10/2005
SE351a, ECE UWO 22
11 Oct., 2005 SE351a, ECE UWO, (c) Hamada Ghenniwa 43
Management
Requirements Engineering ProcessRequirements Engineering Process
The problem/Opportunity
requirementselicitation Review
createanalysismodels
developSpecification
build aprototype