1. MADALINA CROITORU croitoru@lirmm.fr Software Engineering week 3 Madalina Croitoru IUT Montpellier

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

3. MADALINA CROITORU croitoru@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

4. MADALINA CROITORU croitoru@lirmm.fr Code and fix

5. MADALINA CROITORU croitoru@lirmm.fr

6. MADALINA CROITORU croitoru@lirmm.fr Waterfall model Requirement analysis and definition System and software design Implementation and unit testing System testing

7. MADALINA CROITORU croitoru@lirmm.fr Waterfall model

8. MADALINA CROITORU croitoru@lirmm.fr Current challenges

9. MADALINA CROITORU croitoru@lirmm.fr Waterfall model Requirement analysis and definition System and software design Implementation and unit testing System testing

10. The requirements document Specify external behavior Specify constraints on implementation MADALINA CROITORU croitoru@lirmm.fr

11. Requirements document should Be easy to change Reference for systems maintainers Document the expected system lifecycle Describe desired responses to unexpected MADALINA CROITORU croitoru@lirmm.fr

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

13. Role of analyst Elicit requirements Resolve different views Advise what is feasible Clarify requirements Document requirements Negotiate agreement MADALINA CROITORU croitoru@lirmm.fr

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

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

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

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

18. Requirements documents Complete: all services to be provided Consistent: no contradictions Structural Systematic Free of implementation bias MADALINA CROITORU croitoru@lirmm.fr

19. Using natural language Lack of clarity Requirements confusion Requirements amalgamation MADALINA CROITORU croitoru@lirmm.fr

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

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

22. (What is a KiByte) MADALINA CROITORU croitoru@lirmm.fr

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

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

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

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

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

28. Kinds of requirements MADALINA CROITORU croitoru@lirmm.fr

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