MADALINA CROITORU Software Engineering week 3 Madalina Croitoru IUT Montpellier

MADALINA CROITORU Software crisis Survey of outcomes from Standish Group 280,000 development projects 1.Successful 2.Cancelled 3.Late, over budget, incomplete

MADALINA CROITORU Goals of software engineering Satisfy user requirements High reliability Low maintenance costs Deliver on time Low production cost High performance Ease of reuse

MADALINA CROITORU Code and fix

MADALINA CROITORU

MADALINA CROITORU Waterfall model Requirement analysis and definition System and software design Implementation and unit testing System testing

MADALINA CROITORU Waterfall model

MADALINA CROITORU Current challenges

MADALINA CROITORU 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 CROITORU

Requirements document should Be easy to change Reference for systems maintainers Document the expected system lifecycle Describe desired responses to unexpected MADALINA CROITORU

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 CROITORU

Role of analyst Elicit requirements Resolve different views Advise what is feasible Clarify requirements Document requirements Negotiate agreement MADALINA CROITORU

How to get requirements Talk to the user: –Listen –Ask –Record Clarify views: –Resolve inconsistencies –Generate a consensus Important to involve all stakeholders MADALINA CROITORU

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 CROITORU

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 CROITORU

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 CROITORU

Requirements documents Complete: all services to be provided Consistent: no contradictions Structural Systematic Free of implementation bias MADALINA CROITORU

Using natural language Lack of clarity Requirements confusion Requirements amalgamation MADALINA CROITORU

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 CROITORU

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 CROITORU

(What is a KiByte) MADALINA CROITORU

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 CROITORU

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 CROITORU

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 CROITORU

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 CROITORU

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 CROITORU

Kinds of requirements MADALINA CROITORU

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 CROITORU