Other Requirements Supplementary Specification Vision Fundamental OOA/D Skills From Inception to Elaboration

1. Other RequirementsSupplementary Specification Vision Fundamental OOA/D Skills From Inception to Elaboration shivamkushwaha Imb2011009 Course professor – Dr Vijay Kr Chaurasiya

2. Four phases of the Unified Process • Source- wikipedia

3. Inception • Inception is phase of the project • Inception is “Envision the product scope, vision, and business case” “Vision and obtaining an order-of-magnitude estimate necessitates doing some requirements exploration”

4. Inception: An Analogy For Example- In the oil business, when a new field is being considered, some of the steps include: 1. Decide if there is enough evidence or a business case to even justify exploratory drilling. 2. If so, do measurements and exploratory drilling. 3. Provide scope and estimate information. 4. Further steps...

6. USE -CASE MODEL Use cases are a widely used mechanism to discover and record requirements (especially functional); they influence many aspects of a project, including OOA/D In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a human or an external system. Source- Wikipedia

7. IDENTIFYING OTHER REQUIREMENTS • Supplementary Specification • Glossary • The Vision

8. Supplementary Specification Documentation costs money and takes time. Use only enough resources to produce the desired results efficiently and effectively. • Documentation • Packaging • Licensing • Supportability

9. Supplementary Specification(Ex-POS) Revision history

10. Supplementary specification contd.. Functionality (Functionality common across many use cases) Logging and Error Handling Log all errors to persistent storage Usability Human Factors The customer will be able to see a large-monitor display of the POS.Therefore: ï Text should be easily visible from 1 meter.

11. ï Avoid colors associated with common forms of color blindness. Speed, ease, and error-free processing are paramount in sales processing, as the buyer wishes to leave quickly, or they perceive the purchasing experience (and seller) as less positive. Reliability Recoverability If there is failure to use external services (payment authorizer, accounting system, try to solve with a local solution (e.g., store and forward) in order to still complete a sale

12. Performance As mentioned under human factors, buyers want to complete sales processing very quickly. Our goal is to achieve authorization in less than 1 minute, 90% of the time. Supportability Adaptability Different customers of the NextGen POS have unique business rule and processing needs while processing a sale

13. Configurability Different customers desire varying network configurations for their POS systems, such as thick versus thin clients, two-tier versus N-tier physical layers. Therefore, the system will be somewhat configurable to reflect these needs Implementation Constraints NextGenleadership insists on a Java technologies solution, predicting this will improve long-term porting and supportability, in addition to ease of development.

14. Constraints Design Purchased Components ï Tax calculator. Must support pluggable calculators for different countries. Free Open Source Components In general, we recommend maximizing the use of free Java technology open source components on this project.

15. Interfaces • User Interfaces • Hardware Interfaces • Software Interfaces • Communications Interfaces

16. Hardware and Interfaces • Touch screen monitor (this is perceived by operating systems as a regular monitor, and the touch • Gestures as mouse events) • Barcode laser scanner (these normally attach to a special keyboard, and the scanned input is per ceived in software as keystrokes) • Receipt printer • Credit/debit card reader • Signature reader

17. Domain Rules • Domain or Business Rules are not functional requirements. Domain Rules tell how the business works, while functional requirements tell how the system works. Company policies, the laws of physics, and government regulations are examples of Domain Rules. • Do not include system features.

20. Legal Issues We recommend some open source components if their licensing restrictions can be resolved to allow resale of products that include open source software. All tax rules must, by law, be applied during sales. Note that these can change frequently. Applicable Stanards This section describes by reference any applicable standards and the specific sections of any such standards that apply to the system being described. For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, and so forth.

21. The Vision • The Vision serves to communicate to project sponsors and key stakeholders the reasons for the project, the problems to be solved, a description of the stakeholders and their needs, along with a description of the proposed solution. It includes the core requirements and becomes the contractual basis to develop further requirements.

22. Introduction Positioning Business Opportunity Problem Statement Product Position Alternatives Competition Stakeholders Market Demographics Non-user Interests User Interests Key goals and problems for stakeholders User Goals and environment Topics for a Vision

23. Why system features in Vision? • Use cases are not the only way to describe functional requirements. Sometimes a succinct list of key functional requirements will give a better immediate grasp of the problem and proposed solution.

24. Summary of Benefits

25. Summary of System Features • sales capture • payment authorization (credit, debit, check) • system administration for users, security, code and constants tables, and so forth. • automatic offline sales processing when external components fail • real-time transactions, based on industry standards, with third-party systems, including inventory, accounting, human resources, tax calculators, and payment authorization services

26. Glossary • The Glossary captures terms and their definitions in the business domain supported by the system. • Even simple terms may mean different things to different stakeholders and need to be defined. • The Glossary can also perform the role of a Data Dictionary, or be supplemented by one.

27. Glossary (Data Dictionary) • Glossary is a list of noteworthy terms and their definitions. It is surprisingly common that a term, often technical or particular to the domain, will be used in slightly different ways by different stakeholders; this needs to be resolved to reduce problems in communication and ambiguous requirements. • The goal is not to record all possible terms, but those that are unclear, ambiguous, or which require some kind of noteworthy elaboration, such as format information or validation rules

28. Data Dictionary • During elaboration, it may expand into a data dictionary. Term attributes could include: aliases • description • format (type, length, unit) • relationships to other elements • range of values • validation rules

29. Summarization Artifacts and their timing

31. From Inception to Elaboration From Inception to Elaboration

32. Objectives • Elaboration is the initial series of iterations during which the team does the following • Serious investigation • Discover & stabilize major requirements • Mitigate/retire risks ( business value ) • Build core architecture elements • Estimate overall schedule and resources • Establish a supporting environment

33. Inception - Artifacts and Activities • Short Requirements workshop • Naming most actors, goals, use cases • Keep use cases brief (10-20% are in fully dressed) • Identify most risky & influential quality requirements • First version of Supplementary Specification and vision are written

34. Inception - Artifacts and Activities • Risk list (including deadlines on demo) • Technical feasibility investigation (does the requirements supported by our used technology? ) • UI oriented prototypes to clarify vision • Buy/build/reuse components (ex: recommendations to buy a tax calculator) • High-level candidate architecture (a rough estimate of various accessories; a java front end? ) • Plan for the first iteration • Candidate tools list

35. Elaboration • Elaboration is the initial series of iterations during which the team does serious investigation, implements (programs and tests) the core architecture, clarifies most requirements, and tackles the high-risk issues • Build the core architecture, resolve the high-risk elements, define most require- ments, and estimate the overall schedule and resources.

36. Elaboration - Key Ideas • Not a waterfall model ! • Two to six weeks for each iteration • Timeboxed iterations (deadlines should be strictly maintained) • Each iteration products ends in a stable and tested release

37. Architecture Prototype/Baseline • Not a partial system • Evolutionary prototype of final product • Don’t create throw-away prototypes • Production subset of final system • Also called Executable Architecture

38. Best Practices • Start programming early • Adapt based on feedback from tests, users, developers • Design, implement and test adaptively • Test early and realistically • Requirements and use case details through series of workshops (once per iteration)

39. Requirements and Iterations ranking depends on…. • Risk -includes technical complexity and other factors. • Coverage -whether all major parts are covered or not. • Criticality -functions of high business value.

40. Ranking • Rank work across iterations • High ranking scenarios in early iterations (ex: process sales, logging, etc.) • Rank adaptively

41. UP Artifacts planning • Iteration Plan:- only the next iteration is planned • Change Request:- plan written in greater detailed whenever necessary • Software Development Plan:- overall requirement ranking is recorded.

42. Artifacts starting in Elaboration • Domain Model (conceptual class diagram) • Design Model(logical design: class diagram, object oriented diagram, etc.) • Software Architecture Document (summary of ideas and motivations) • Data Model (database schemas..) • Test Model • Implementation Model (source code, databases) • Use-Case Storyboards and UI Prototypes (description of user interfaces, navigations etc.

43. Inception and Elaboration • Main output is a stable software architecture, that enables quality planning of Construction and Deployment • 15 to 25 percent of total project cost

44. You didn’t Understand Elaboration When … • No Timeboxed schedule • Single Iteration • Most requirements already defined • No Risk mitigation/resolution • No Executable Architecture • Requirements Phase • Attempt full and careful design

45. You didn’t Understand Elaboration • Minimal feedback and adaptation • No early and realistic testing • Frozen Architecture • No Proof-of-concept programming • No multiple requirements workshops

46. References • Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. ISBN 0-13-111155-8 • Wikipedia • Scott, Kendall (2002). The Unified Process Explained. ISBN 0-201-74204-7 • www.scribd.com

47. Thank you