MADALINA CROITORU [email protected] Software Engineering week 3 Madalina Croitoru IUT Montpellier

MADALINA [email protected]

Software Engineeringweek 3

Madalina CroitoruIUT Montpellier


Software crisisSurvey of outcomes

from Standish Group

280,000 development projects

1. Successful

2. Cancelled

3. Late, over budget, incomplete

128%

223%

349%


Goals of software engineering

• Satisfy user requirements

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


Code and fix



Waterfall model

• Requirement analysis and definition

• System and software design

• Implementation and unit testing

• System testing


Waterfall model


Current challenges


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


Requirements document should

• Be easy to change• Reference for systems

maintainers• Document the

expected system lifecycle

• Describe desired responses to unexpected


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


Role of analyst

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

requirements• Negotiate agreement


How to get requirements

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

• Clarify views:– Resolve inconsistencies– Generate a consensus

• Important to involve all stakeholders


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


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)








Requirements documents

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


Using natural language

• Lack of clarity• Requirements confusion• Requirements amalgamation








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


(What is a KiByte)


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


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?



• 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?


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?


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?




Requirements Validation

• Showing that the requirements define the system that the customer wants

• Invalid requirements are very expensive

• Requirements have to be:– Complete– Correct


Documents

MADALINA CROITORU [email protected] Software Engineering week 3 Madalina Croitoru IUT Montpellier