madalina croitoru croitoru@lirmm.fr software engineering week 3 madalina croitoru iut montpellier

MADALINA CROITORUcroitoru@lirmm.fr

Software Engineeringweek 3

Madalina CroitoruIUT Montpellier

MADALINA CROITORUcroitoru@lirmm.fr

Software crisisSurvey of outcomes

from Standish Group

280,000 development projects

1. Successful

2. Cancelled

3. Late, over budget, incomplete

128%

223%

349%

MADALINA CROITORUcroitoru@lirmm.fr

Goals of software engineering

• Satisfy user requirements

• High reliability• Low maintenance costs• Deliver on time• Low production cost• High performance• Ease of reuse

MADALINA CROITORUcroitoru@lirmm.fr

Code and fix

MADALINA CROITORUcroitoru@lirmm.fr

MADALINA CROITORUcroitoru@lirmm.fr

Waterfall model

• Requirement analysis and definition

• System and software design

• Implementation and unit testing

• System testing

MADALINA CROITORUcroitoru@lirmm.fr

Waterfall model

MADALINA CROITORUcroitoru@lirmm.fr

Current challenges

MADALINA CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

Requirements document should

• Be easy to change• Reference for systems

maintainers• Document the

expected system lifecycle

• Describe desired responses to unexpected

MADALINA CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

Role of analyst

• Elicit requirements• Resolve different views• Advise what is feasible• Clarify requirements• Document

requirements• Negotiate agreement

MADALINA CROITORUcroitoru@lirmm.fr

How to get requirements

• Talk to the user:– Listen– Ask– Record

• Clarify views:– Resolve inconsistencies– Generate a consensus

• Important to involve all stakeholders

MADALINA CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

Requirements documents

• Complete: all services to be provided• Consistent: no contradictions• Structural• Systematic• Free of implementation bias

MADALINA CROITORUcroitoru@lirmm.fr

Using natural language

• Lack of clarity• Requirements confusion• Requirements amalgamation

MADALINA CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

(What is a KiByte)

MADALINA CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr

Kinds of requirements

MADALINA CROITORUcroitoru@lirmm.fr

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 CROITORUcroitoru@lirmm.fr