1. CSC 402 Requirements Engineering 1 Overview - Software Lifecycles, Processes, Methods and Tools Software lifecycle basics Software lifecycles – build-and-fix – waterfall – rapid prototype – incremental – spiral Process improvement – CMM & ISO9000 Methods and Tools

2. CSC 402 Requirements Engineering 2 Software Lifecycle A series of steps through which a software product progresses Lifetimes vary from days to months to years Consists of – people! – overall process – intermediate products – stages of the process

3. CSC 402 Requirements Engineering 3 Software Production Personnel Client (customer) – individuals or organizations that want the solution ¤ to a problem they have Developer(s) – (members of) an organization producing the solution ¤ to THAT problem User(s) – person who authorizes client to contract with developer – person(s) who will utilize the software solution Internal software development vs external contract – and all the shades of gray!

4. CSC 402 Requirements Engineering 4 What is a process? “Device” for producing a product (get job done) Level of indirection – Process description describes wide class of instances Humans create process descriptions to solve classes of problems Thus – software processes are “devices” for creating and evolving software products ¤ what is this about?

5. CSC 402 Requirements Engineering 5 Intermediate Software Products Objectives – Mark the “end” of phases – Enable effective reviews – Specify requirements for next phase ¤ Note the abstract requirements/design cycle Form – Rigorous – Machine processible (highly desirable) Content – Specifications, Tests, Documentation

6. CSC 402 Requirements Engineering 6 Phases of a Software Lifecycle Standard Phases – Requirements Analysis & Specification – Design – Implementation and Integration – Operation and Maintenance – Change in Requirements – Testing throughout Phases promote manageability and provide organization

7. CSC 402 Requirements Engineering 7 Requirements Analysis and Specification Problem Definition —> Requirements Specification – determine exactly what is the client (and user) problem ¤ in their environment - with their environmental constraints – develop a contract with client ¤ exactly what the software/computer solution will do Difficulties – client asks for wrong product or developer “knows better” (want vs need) – client is computer/software illiterate or developer domain illiterate – specifications will be ambiguous, inconsistent, incomplete (adequacy?) Validation – extensive specification reviews check that requirements satisfy client wants – look for ambiguity, consistency, incompleteness – check for feasibility, testability – develop system/acceptance test plan

8. CSC 402 Requirements Engineering 8 Design Requirements Specification —> Design – develop architectural design (system structure): decompose software into modules with module interfaces – develop detailed design (module specifications): select algorithms and data structures – maintain record of design decisions and traceability – how the product is to do its task Difficulties – can’t design one of those (feedback to requirements?) – miscommunication between module designers – design may be inconsistent, incomplete, ambiguous ¤ question: “when can the programmer make this decision for the client?” with all that entails Verification – extensive design reviews (inspections with checklists) to determine that design conforms to requirements – check module interactions – develop integration test plan

9. CSC 402 Requirements Engineering 9 Implementation and Integration Design —> Implementation – implement modules and verify they meet their specifications – combine modules according to architectural design – how the product does its task Difficulties – can’t build one of those (feedback to design or requirements?) – module interaction errors – order of integration has a critical influence on product quality and productivity Verification and Testing – extensive code reviews (inspections with checklists) to determine that implementation conforms to requirements and design – develop and test on unit/module test plan: focus on individual module functionality – test on integration test plan: focus on module interfaces – test on system test plan: focus on requirements and determine whether product as a whole functions correctly

10. CSC 402 Requirements Engineering 10 Operation and Maintenance Operation —> Change – maintain software after (and during) user operation – integral part of process – determine whether product as a whole still functions correctly Difficulties – design not extensible – lack of up-to-date documentation – personnel turnover Verification and Testing – extensive review to determine that change is made correctly and all documentation updated – test to determine that change is correctly implemented – test to determine that no inadvertent changes were made to compromise system functionality (check that no affected software has regressed)

11. CSC 402 Requirements Engineering 11 Build-and-Fix Build First Version Retirement Operations Mode Modify until Client is satisfied

12. CSC 402 Requirements Engineering 12 Waterfall Requirements Verify Retirement Operations Test Implementation Verify Design Req. Change

13. CSC 402 Requirements Engineering 13 Rapid Prototyping Rapid Prototype Verify Retirement Operations Test Implementation Verify Design Req. Change

14. CSC 402 Requirements Engineering 14 For each build: Perform detailed design, implement. Test. Deliver. Incremental Requirements Verify Retirement Operations Verify Arch. Design

15. CSC 402 Requirements Engineering 15 The Spiral Model [Boehm,1988]

16. CSC 402 Requirements Engineering 16 (Extremely) Simplified Spiral Model Requirements Verify Retirement Operations Test Implementation Verify Design Req. Change Add a Risk Analysis step to each phase! Risk Assessment

17. CSC 402 Requirements Engineering 17 CMM is not a software lifecycle model... – Strategy for improving the software development process regardless of the process “model” followed ¤ Basic premise: the use of new software methods alone will not improve productivity and quality, because software management is, in part, the cause of problems – CMM assists organizations in providing the infrastructure required for achieving a disciplined and mature process ($$) Includes – technical aspects of software production – managerial aspects of software production Capability Maturity Model (CMM) [Watts Humphrey,1989, author of PSP]

18. CSC 402 Requirements Engineering 18 Capability Maturity Model (continued) Five maturity levels – 1. initial – ad hoc process – 2. repeatable process – basic project management – 3. defined process – process modeling and definition – 4. managed process – process measurement – 5. optimizing process – process control and dynamic improvement to move from one stage to the next, the SEI provides a series of questionnaires and conducts process assessments that highlight current shortcomings

19. CSC 402 Requirements Engineering 19 ISO 9000 Further attempt to improve software quality based on International Standards Organization (ISO) ISO 9000 = series of five related standards – within ISO 9000 standard series ISO 9000-3 focuses on software and software development Basic features: – stress on documenting the process in both words and pictures – requires management commitment to quality – requires intensive training of workers – emphasizes measurement Adopted by over 60 countries (USA, Japan, European Union,...) To be ISO 9000 compliant, a company’s process must be certified

20. CSC 402 Requirements Engineering 20 Software Methods and Tools Methods provide a means or procedure for accomplishing a task Tools are devices for performing some task – analytical tools – software tools Methodology guides the proper use of methods and tools Process helps to enact a methodology Environments are a synergistic collection of tools with process support

21. CSC 402 Requirements Engineering 21 Analytical Tools Problem solving techniques that help in software development – cost-benefit analysis ¤ compare expected benefits against estimated costs – stepwise refinement ¤ divide and conquer – abstraction ¤ focus on some important property and ignore (for the time being) irrelevant details Analytical tools underlie many software development methods

22. CSC 402 Requirements Engineering 22 Software Tools Software tools are an automated implement for performing a task Tools facilitate work because they are – fast, immune to boredom and "cheating" Software Tools should be... – powerful, effective, convenient, natural, reliable, robust – Most are not ¤ exceptions: compilers, editors, loaders these have been polished, refined, and debugged through long-term use and hence made reliable and robust these have been made natural and effective through extended exposure and maintenance

23. CSC 402 Requirements Engineering 23 Tool Obstacles Tool use obstacles – developers tend to be like hammer and screwdriver carpenters – tools are not powerful and/or effective – tools are unreliable and/or not robust ¤ comes with time and money – tools are inconvenient and/or unnatural ¤ comes from successful use Tool building obstacles – Short history of large-scale software development – Limited success in ¤ developing software well ¤ exploiting “tools” successfully – Few software techniques have had time and use required to achieve tool status – No “tools” at all in some key areas (e.g., real-time analysis)

24. CSC 402 Requirements Engineering 24 Requirements Focus Requirements determine the “What” of a software product’s functionality. (But see Jackson!) Requirements analysis and specification transforms – informal product definition into – formal requirements specification A step in between is transforming the product definition into a natural language statement of the system’s functionality – precise, yet abstract (how do we do this?!?)

25. CSC 402 Requirements Engineering 25 What about Reality? Is a rational process of software development possible? (desirable?) – Parnas: No! We should fake it, though (1986) ¤ people don’t know what they want? ¤ don’t know everything at outset, backtracking inevitable? ¤ human beings not good at big, complex problems? ¤ changes occur in the environment (out of our control)? ¤ human errors only avoidable if we avoid the use of humans can we? ¤ preconceived notions (favorite ideas, like language wars) ¤ reuse and other economic factors – Rank order these (most often, most expensive during development, most costly in later use?)

26. CSC 402 Requirements Engineering 26 What does the sincere developer do? Parnas says “fake the rational process...” - – designers need guidance - helps us proceed – better than ad hoc - we can at least aim high – organizational advantages to standard procedure ¤ reviews, transfer of workers, ideas and software – if we agree on an ideal process, we can measure progress along that dimension – external reviews made possible and useful ¤ because others will understand the standards

27. CSC 402 Requirements Engineering 27 Why have a Requirements Document? Record desired behavior of system: build the solution the the right problem – that user or customer can review for adequacy ¤ we don’t want a random variation on the “correct” solution Avoid making customer decisions by programming! – what can happen here? consider systems engineering Avoid duplication and inconsistency – many would argue, the requirements doc can answer questions ¤ a master’s thesis: prototype AS requirements

28. CSC 402 Requirements Engineering 28 Why? (continued) A complete requirements doc is necessary to make good estimates (not sufficient though!) Valuable insurance against staff turnover Test plan development

29. CSC 402 Requirements Engineering 29 More Can be used, long after system in use, to define constraints for future changes – senior project: “never too late to do requirements”

30. CSC 402 Requirements Engineering 30 Synchronization Read Wiegers Read Yourdon Read Jackson Develop questions you might ask customer – dynamically develop questions during customer presentations to review later and refine – if you get a good answer, record it as well as you can

31. CSC 402 Requirements Engineering 31 (continued) – each team member should keep notes ¤ team meeting afterwards to gather notes to make a preliminary report of questions asked answered obtained overview of domain overview of problem as described other comments of note