madalina croitoru [email protected] software engineering week 3 madalina croitoru iut montpellier
TRANSCRIPT
MADALINA [email protected]
Software crisisSurvey of outcomes
from Standish Group
280,000 development projects
1. Successful
2. Cancelled
3. Late, over budget, incomplete
128%
223%
349%
MADALINA [email protected]
Goals of software engineering
• Satisfy user requirements
• High reliability• Low maintenance costs• Deliver on time• Low production cost• High performance• Ease of reuse
MADALINA [email protected]
Code and fix
MADALINA [email protected]
MADALINA [email protected]
Waterfall model
• Requirement analysis and definition
• System and software design
• Implementation and unit testing
• System testing
MADALINA [email protected]
Waterfall model
MADALINA [email protected]
Current challenges
MADALINA [email protected]
Waterfall model
• Requirement analysis and definition
• System and software design
• Implementation and unit testing
• System testing
The requirements document
• Specify external behavior
• Specify constraints on implementation
MADALINA [email protected]
Requirements document should
• Be easy to change• Reference for systems
maintainers• Document the
expected system lifecycle
• Describe desired responses to unexpected
MADALINA [email protected]
Requirements analysis and specifications
• Involves:– Feasibility study– Requirements analysis– Requirements definition– Requirements validation– Requirements specifications
• AIM: complete, official statement of what developers are required to do
MADALINA [email protected]
Role of analyst
• Elicit requirements• Resolve different views• Advise what is feasible• Clarify requirements• Document
requirements• Negotiate agreement
MADALINA [email protected]
How to get requirements
• Talk to the user:– Listen– Ask– Record
• Clarify views:– Resolve inconsistencies– Generate a consensus
• Important to involve all stakeholders
MADALINA [email protected]
Why analysis is hard
• Stakeholders do not know what they want
• Stakeholders have unrealistic expectations
• Stakeholders use their own language• Different stakeholders have different
requirements• Political factors• Economic / business factors
MADALINA [email protected]
Requirements definition
• A high - level, customer – oriented statement of what system is to do
• Two types of requirements:– Functional: services the systems should
provide, how it responds to inputs, how it behaves, what is should NOT do
– Non-functional: constraints the system should operate under (Pentium, X RAM, Y hard disk)
MADALINA [email protected]
Requirements definition
• A high - level, customer – oriented statement of what system is to do
• Two types of requirements:– Functional: services the systems should
provide, how it responds to inputs, how it behaves, what is should NOT do
– Non-functional: constraints the system should operate under (Pentium, X RAM, Y hard disk)
MADALINA [email protected]
Requirements documents
• Complete: all services to be provided• Consistent: no contradictions• Structural• Systematic• Free of implementation bias
MADALINA [email protected]
Using natural language
• Lack of clarity• Requirements confusion• Requirements amalgamation
MADALINA [email protected]
Requirements definition
• A high - level, customer – oriented statement of what system is to do
• Two types of requirements:– Functional: services the systems should
provide, how it responds to inputs, how it behaves, what is should NOT do
– Non-functional: constraints the system should operate under (Pentium, X RAM, Y hard disk)
MADALINA [email protected]
Non-functional Requirements
• Speed:– No of transactions per second– User / event response time– Screen refresh time
• Size:– Kibytes– RAM
• Ease of use:– Required average training time– Number of help screens
MADALINA [email protected]
(What is a KiByte)
MADALINA [email protected]
Non functional Requirements
• Reliability:– Mean time to failure– Availability
• Robustness:– Time to restart after failure– Percentage of events causing failure– Freedom from data corruption on failure
MADALINA [email protected]
Kinds of requirements
• Physical environment:– Where will it function– Is there one/ more locations– Are there environmental restrictions?
• Interfaces:– Input coming from one / more systems?– Output going to one / more systems?– Prescribed medium for input /output?
MADALINA [email protected]
Kinds of requirements
• User and human interfaces:– Who will use the system?– Will there be several types of users?– What is the skill level of each?– What training is required?
• Functionality:– What the system does?– When the system does it?
MADALINA [email protected]
Kinds of requirements• Documentation:
– How much documentation is required?– What audience is the document intended for?– What help features are provided?
• Data:– Input / output format?– How often received / sent?– Accurate? What precision?– Data must be retained?
MADALINA [email protected]
Kinds of requirements• Security:
– Must access to system be controlled?– How to isolate user’s data?– How often to do backups?– Where store backups?
• Quality assurance:– Requirements for reliability?– Mean time between failure?– What faults to be captured?
MADALINA [email protected]
Kinds of requirements
MADALINA [email protected]
Requirements Validation
• Showing that the requirements define the system that the customer wants
• Invalid requirements are very expensive
• Requirements have to be:– Complete– Correct
MADALINA [email protected]