1. Software Engineering 1. Software development – the grand view 2. Requirements engineering

2. Software development Collection of activities, organised in different ways according to:  Specific software development methodology  Specific software product characteristics  Specific project characteristics (team, budget, organisational culture, etc.)

3. Software development Activities: Problem definition Requirements Construction planning High-level design Detailed design Coding and debugging Unit testing Integration testing Integration System testing Corrective maintenance

4. Software development Organisation of activities: Waterfall (linear, sequential): Desirable, but rarely applicable (...)

5. Software development Organisation of activities: Prototyping: requirements prototype tests

6. Software development Organisation of activities: RAD (Rapid Application Development): (...) Team 1: (...) Team 2: (...) Team 3: (...)

7. Software development Organisation of activities: Spiral: Requirements Planning Risk analysis Engineering Construction Evaluation

8. Software development Organisation of activities: Agile: Scrum, XP Concurrent Component-based

9. Software development In this course: Software construction

10. Activities: Problem definition Requirements Construction planning High-level design Detailed design Coding and debugging Unit testing Integration testing Integration System testing Corrective maintenance

11. Software development Common metaphors:  Developing software = writing a text Applicable only for small scale individual projects, and even then not so good metaphor. Underlying idea is that writing software is “artistic craftsmanship”: build a model, do not show it to anyone, evaluate it, throw it away, build a new one from scratch and then present your masterpiece to the world...

12. Software development Common metaphors:  Developing software = building a house Different situations imply different construction problems and techniques (doghouse, family house, shopping center, skyscraper,...) Team work Plan ahead Use standardised and pre-fabricated components Be disciplined

13. Software development Always have a plan is completely different from Never change your plan Planning is a dynamic activity, that should follow the dynamics of external reality. Plans should be permanently revised.

14. Software requirements Requirements are dynamic... but must not be chaotic Requirements should be updated as project goes along, but some degree of stability must be assured so that project can be developed.

15. Requirements checklist (Copied directly from Code Complete, 2nd. edition) Specific functional requirements:  Are all inputs specified, including source, accuracy, range of values and frequency?  Are all outputs specified, including destination, accuracy, range of values and frequency?

16. Requirements checklist  Are all output formats specified (reports, graphics, etc.)?  Are all external hardware and software interfaces specified?  Are all external communication interfaces specified, including hand-shaking, error- checking and communication protocols?  Are all tasks desired by the user specified?  Is the data required by each task and the data resulting from each task specified?

17. Requirements checklist Specific non-functional requirements:  Is the expected response time, from the user’s point of view, specified for all operations?  Are other timing considerations specified, e.g. processing time and data transfer rate?  Is the level of security specified?

18. Requirements checklist  Is the reliability specified, including Consequences of failure Vital information that needs to be protected from failure Strategy for error detection and recovery?  Are minimum machine memory and free disk space specified?

19. Requirements checklist  Is the maintainability of the system specified, including Ability to adapt to changes in specific functionality Changes in the operating environment Changes in interfaces with other software?  Is the definition of success included?  Is the definition of failure included?

20. Requirements checklist Requirements quality:  Are the requirements written in the user’s language? Do the users think so?  Does each requirement avoid conflicts with other requirements?  Are acceptable tradeoffs between competing attributes specified?

21. Requirements checklist  Do the requirements avoid specifying the design?  Are the requirements specified at the appropriate level of detail?  Are the requirements clear enough to be delivered to an independent group? Do the developers think so?

22. Requirements checklist  Is each item relevant to the problem and its solution?  Is each requirement testable?  Are all possible changes to the requirements specified, including the likelihood of each change?

23. Requirements checklist Requirements completeness:  Some information may not be available before development begins. Are all areas of incompleteness specified?  If the product satisfies every requirement, will it be acceptable?  Is there any requirement that is impossible to implement, which was included to appease your customer or your boss?