Lecture 03

1. Lecture 03 ITEC 4040 – Requirements Management Prof. DawidKasperowicz http://www.yorku.ca/dkasper

2. Prototyping • Prototypes are small-scale models, or initial versions of a system that is available early in the development process • A miniature car • A miniature building or town • In hardware systems, prototypes are often developed to test and experiment with system designs • In software systems, prototypes are more often used to help elicit and validate the system requirements ITEC 4040 – Requirements Management

3. Prototyping • An essential requirement for a prototype is that it should be possible to develop it quickly so it can be used during the development process • To achieve this, we may leave out functionality, normal mechanisms of management and quality assurance, and non-functional requirements • Different technologies may be used to develop the prototype than are used for the final system ITEC 4040 – Requirements Management

4. Why Prototype? • Evaluation, analysis and verification of requirements • Stakeholders can see, hold, interact with a prototype more easily than a document or a drawing • Team members can communicate effectively • Test out ideas • Encourage reflection • Answer questions, and support decision making between alternatives • If omitted, the first release actually becomes the prototype ITEC 4040 – Requirements Management

5. Why Prototype? • Help establish the overall feasibility and usefulness of the system before high development costs are incurred • Can reduce later development costs for the system • 10% - 25% reduction in requirements creep • Helps reveal requirements inconsistencies and incompleteness due to requiring a study of requirements • Most find prototyping is worthwhile, despite increased initial development costs • Requirements are more likely to reflect the real needs • Less requirements rework ITEC 4040 – Requirements Management

6. Low-Fidelity Prototyping • Uses a medium which is unlike the final medium • Paper, cardboard • Is quick, cheap and easily changed • Examples: • Sketches of screens, task sequences, etc. • “Post-it” notes, storyboards, etc. ITEC 4040 – Requirements Management

7. High-Fidelity Prototyping • Uses materials that you would expect to be in the final product • Prototype looks more like the final system than a low-fidelity version • Danger that users think they have a full system • Argued more projects should use low-fidelity prototyping because of the inherit problems with high-fidelity prototyping: • They take too long to build • Reviewers and testers tend to comment on superficial aspects rather than content • Developers are reluctant to change something they have crafted for hours • A software prototype can set expectations too high • Just one bug in a high-fidelity prototype can bring the testing to a halt ITEC 4040 – Requirements Management

8. Low- Vs. High-Fidelity Prototypes ITEC 4040 – Requirements Management

9. Compromises in Prototyping • All prototypes involve compromises • For software-based prototyping, there might be slow responses and limited functionality • Two common types of compromises • Horizontal – Provides a wide range of functions, but with little detail • Vertical – Provides a lot of detail for only a few functions ITEC 4040 – Requirements Management

10. Prototype Breeds • Throw-away prototypes • Discarded when their purpose has come to fruition • Intended to help elicit and develop the system requirements • Requirements causing most difficulty are prototyped • Evolutionary prototypes • A system with limited functionality is continuously modified and extended and eventually becomes the final system • Intended to deliver a workable system quickly • Well understood requirements are supported first • Evolutionary prototyping has short-term gains and long-term costs • Poorly structured so cost of maintenance and system evolution is high • Historically have short lifetime ITEC 4040 – Requirements Management

11. Problems with Prototyping and Solutions • Biggest problems: • Developers get carried away and go into far too much detail • Prototypes tend to cause stakeholders to stray into implementation • Stakeholders may be so impressed with the prototype that they want to use it operationally • Solutions: • Treat prototyping as a small sub-project with its own stakeholder requirements • Always clearly indicate the objective (provide greater insight to stakeholder requirements) • Ensure stakeholders are fully aware of the illusionary nature of a prototype ITEC 4040 – Requirements Management

12. Reverse Engineering • From existing code figure out requirements for the system • Positives • Information availability(code) • Reuse • Negatives • Information discontinuity • Many old requirements may not be needed anymore • Many new requirements may not be present in current versions of the software • Very detailed information ITEC 4040 – Requirements Management

13. Requirements Reuse • It’s generally good system and software engineering practice to reuse as much knowledge as possible when developing something new • There are situations where reusing requirements across systems may be possible, even though systems are different conceptually and have unique stakeholders • More than 50% of requirements may fall into these situations, and reusing them can be significantly cost saving ITEC 4040 – Requirements Management

14. Requirements Reuse • Situations include: • When the requirement is concerned with providing information about the universe of discourse • Requirements wont specify system functionality but constraints on the system or its operations that is usually found in the universe of discourse • E.g.: A train breaking system specification including how the mass, speed of the train affect the time it takes the train to stop. This information is likely to be found with all train control and protection systems ITEC 4040 – Requirements Management

15. Requirements Reuse • Situations include: • When requirements are concerned with the style of presentation of information • Makes sense companies want to have a consistent “look and feel” for user interfaces for all their systems to decrease user errors moving between systems ITEC 4040 – Requirements Management

16. Requirements Reuse • Situations include: • When requirements reflect company policies • Security policies are often reflected in system requirements and when used in one system, it may be reused in later systems • E.g.: Company has a policy to encrypt personal information. A common requirement for encryption may be common to a number of different systems ITEC 4040 – Requirements Management

17. Requirements Reuse • Reused requirements have already been analysed and validated in other systems • Time needed to validate and analyze these requirements is still needed to if they are appropriate, this time is less than new requirements • Danger of unanticipated interactions between reused and new requirements resulting in considerable rework • Always assume old requirements are “dirty”, and they need to be analyzed and validated • Reuse is not a silver bullet and can open a “Pandora’s Box” if inappropriate assumptions are made about the applicability of the requirements or if the requirements are derived from sources that have inherent problems ITEC 4040 – Requirements Management

18. General Reuse Types • Four types: • Incidental Reuse • Planned Reuse • Incremental Capability • COTS ITEC 4040 – Requirements Management

19. General Reuse Types: Incidental Reuse • Most common form involving system developed for one purpose or application in a new application • Requires being partially redesigned, re-implemented, and retested to ensure it does what it should do, and doesn’t do what it shouldn’t do • Can cause inheriting problems of pre-existing system with few benefits and end up costing more than developing a new system ITEC 4040 – Requirements Management

20. General Reuse Types: Planned Reuse • Involves developing a system with reuse as a goal in its development • Developers spend extra effort to develop system so they can reuse within the same domain • SEER-SEM estimation model estimates systems developed for planned reuse can be up to 63% more expensive ITEC 4040 – Requirements Management

21. General Reuse Types: Incremental Capability • Adding functionality to an existing system through upgrading or incremental deliveries of a system under development ITEC 4040 – Requirements Management

22. General Reuse Types: COTS Commercial Off-the-Shelf Output Input Black Box ITEC 4040 – Requirements Management

23. COTS • Software is built from a 3rd party vendor that can be purchased, leased or licenced to the general public of corporations • Can come in the form of services: • Infrastructure as a Service (IaaS) • Platform as a Service (PaaS) • Software as a Service (SaaS) • Can come in traditional forms • Instead of adapting the software to the company, the company has to adapt itself to the software • Alternative is In-House ITEC 4040 – Requirements Management

24. COTS Selection • Requirements for selecting • Functional Requirements • Non-Functional Requirements • Supplier • Availability • Supported Methodologies • Training • Integration • Cost, cost, cost ITEC 4040 – Requirements Management

25. COTS Selection Process • Study the market to see what is available • Select • Adapt • Integrate • Update ITEC 4040 – Requirements Management

26. Requirements for Selecting COTS • Supplier’s reputation and maturity • Guaranties given by the suppliers for support • Supplier’s stability • Possibility of changing the product in the future versions ITEC 4040 – Requirements Management

27. Factors Influencing COTS Selection • Time to get a final selection of products • Number of possible COTS • Availability of a user group • Resources available for evaluation and selection activities • Has this product been used before? ITEC 4040 – Requirements Management

28. COTS Risks • Generally assumed COTS are relatively bug-free. Reality is newer less tested versions cause defects to reappear • Manuals do not always say everything, and so involves a learning curve • Always need to verify when using COTS • Custom development is usually needed to meet the majority of requirements ITEC 4040 – Requirements Management

29. COTS Pros. and Cons. • Advantages • Initial cost • Fast • Development • Time to market • Technical support • User groups • Training • Reliability (sometimes) ITEC 4040 – Requirements Management

30. COTS Pros. and Cons. • Disadvantages • Inflexible because requirements can rarely change • Dictate standards, architecture and design • May not solve all problems • May influence work flow • Does not provide space to improve processes • High learning curve • At the mercy of vendor to correct defects • Vendor may discontinue support or cease business • Choosing wrong one may be more expensive than fixing problems in custom solutions • Potential lack of commonality with other products resulting in integration and information exchange difficulties • Long-term maintenance issues as technology and components upgrade every 6-24 months to meet changing marketplace demands • Changes in the general marketplace can impose unanticipated and unpredictable changes to the COTS ITEC 4040 – Requirements Management

31. Which Technique to Use? • Depends on the situation • Analyse the context • Respect limitations ITEC 4040 – Requirements Management

32. Example • Health Care Domain • Questionnaires • Less than 10% returned • Vast majority just partially filled • Nurses and physicians usually work in a 12 hour shift • Interviews • Lack of trustworthiness • Formality • Open-ended/semi-structured may get better response • List of topics ITEC 4040 – Requirements Management

33. Example • Health Care Domain • Protocol Analysis • Almost impossible (privacy, inconvenient) • Imagine a heart attack • JAD • When the project has to develop fast • Good to solve conflicts • Competitivity ITEC 4040 – Requirements Management

34. Example • Health Care Domain • Video and Auto (transcriptions) • Legal questions make it hard to be used • Use Case and Scenarios • Well accepted • Scenarios are more welcomed • Observation • Confirm results ITEC 4040 – Requirements Management

35. Communicating • Presentation • Understanding • Languages • Level of Abstraction • Feedback ITEC 4040 – Requirements Management

36. Communicating • Presentation – The way the information is shown • Different ways may help or hinder one to understand the information Which is easier to understand? ITEC 4040 – Requirements Management

37. Communicating • Language – The language is the reflection of a societies culture • To understand something that is important to someone, we have to understand the language of that person • Before we can elicit requirements we must understand the language being used • Examples: • Zip a file • NFR • Throughput • Bandwidth • Bus • Cookie • Virus • Trojan ITEC 4040 – Requirements Management

38. Communicating • Level of Abstraction – People speaking in different levels of complexity • Miscommunication can occur when people speak in different levels of abstraction • This is a typical conflict when you place a generalist and specialist together • Example: • VP Sales says “We should conquer new markets” (higher level) • Sales Manager says “We should distribute salesmen” (lower level) ITEC 4040 – Requirements Management

39. Communicating • Level of Abstraction • T. Korson emphasizes the importance of levels of abstraction in requirements gathering • T. Korson’s critical principles of requirement gathering • Start with high-level requirements and work to more detailed levels • Helps with comprehending the scope of the system • Prevents being overwhelmed by the more detailed requirements • Helps gaining insights into the real requirements • Don’t put high-level requirements into detailed specifications • Precludes clients from considering alternatives • Misleads designers/developers ITEC 4040 – Requirements Management

40. Communicating • Level of Abstraction • T. Korson’s critical principles of requirement gathering • Help users’ gain a deeper understanding of their real needs and requirements • Don’t derive the design from use cases, but use your experience ITEC 4040 – Requirements Management

41. Communicating • Feedback – The receiver of information returning information back to the source • We should demand feedback ITEC 4040 – Requirements Management

42. Heuristics for Communication • A good figure is worth 1000 words • Communication should flow in both directions • Avoid noise • Avoid metaphors with your area of communication • Identify different viewpoints • Learn with humility ITEC 4040 – Requirements Management

43. Heuristics for Communication • Generally • Ask what? How? Why? • Who should we talk to? Why? • What to study? Why? • Where to begin? • How to represent? To whom? How? • What are the things in the current system that you don’t like? • Always review! ITEC 4040 – Requirements Management

44. Social Aspects • Ecology of the system: • Metaphor of the physical industrial plant • Before choosing a place and a operational procedure, we must evaluate the disturbances this industrial plant could bring to the environment once it is operational ITEC 4040 – Requirements Management

45. Social Aspects • London Ambulance Service: • System developed almost without consulting the users • The proposed system would significantly impact the way the staff carried out their tasks; however, regarding the several ambulance teams there was only a few questions about the “new proposed way of doing things” ITEC 4040 – Requirements Management

46. Social Aspects • London Ambulance Service: • “The general attitude towards the information system was incredibly positive. Everyone recognized that computers in this area is primordial to enhance efficiency. However, there is a feeling that the actual system and the way it was introduced was the future way. There is no trust in the system which resulted in an expectative of failure instead of success from the staff viewpoint” ITEC 4040 – Requirements Management

47. Social Aspects • London Ambulance Service: • Use the system to change job practices • “The new system would eliminate these practices, the management used to think” • “The result is that the staff saw the changes/new procedures as a straitjacket in which they were trying to find some flexibility” ITEC 4040 – Requirements Management

48. Social Aspects • London Ambulance Service: • Conclusion from the investigation: • The upper management was naïve to believe a system could, by its own power, bring changes to human traditional practices. Experiments in many different environments prove that information systems are not capable to influence changes this way. They can only help on the process and any attempt to force these changes is likely to fail. ITEC 4040 – Requirements Management

49. Social Aspects • Broader View: • Sociology • Groups with the same concerns • Groups of power • Policies and politics ITEC 4040 – Requirements Management

50. Social Aspects • Broader View: • Orthogonal to everything we saw for elicitation • Focus is on the social aspects not technology • Demands more resources • Contrary to the common thinking from commercial packages such as ERP • Important because it is long term focused ITEC 4040 – Requirements Management