1. Rekayasa Kebutuhan Perangkat Lunak Requirements Document Standards

2. Requirements Document Standards (1) Provide Templates – present a document outline for a requirements specification document (including a short content description for each chapter) – help to structure requirements documents ⇒ Several Standards for Requi rements Documents exist: - IEEE Standard 1362-1998 Guide for Information Technology – System Definition – Concept of Operations Document - IEEE Standard 830-1998 Recommended Practice for Software Requirements Specifications - Volere Template (James & Suzanne Robertson, Atlantic Systems Guild) http://www.systemsguild.com/GuildSite/Robs/Template.html

3. Requirements Document Standards (2) Standards tackle different levels of abstraction: – Problem Clarification – IEEE 1362-1998 – Volere Template – Basis for Development – IEEE 830-1998 – Volere Template

4. Requirements Document Standards/Templates - System context Business Processes Stakeholders Rationale (Why is the software developed) -Organizational requirements Constraints Standards -Project Information Cost and Effort Information Risk -Functional requirements What should the system do! -Nonfunctional requirements How good should the system do its job. specified in user doc. (sometimes refined in developer doc.) specified in user doc. specified at high level in user doc. refined in developer doc.

5. Volere Template Developed by James & Suzanne Robertson (The Atlantic Systems Guild) Presents a template that may be used to specify user requirements as well as developer requirements - some template sections describe very detailed information about the system while other sections are very high level (developer vs user) - some template sections can be used for a developer audience as well as a user audience. In these cases either the used notation is the key differentiator or the information contained in the user document is refined in the developer section Available online: http://www.volere.co.uk/template.htm

6. http://www.volere.co.uk/tools.htm

7. Volere Template Overview (1) Project Drivers 1. The Purpose of the Product 2. Client, Customer and other Stakeholders 3. Users of the Product Project Constraints 4. Mandated Constraints 5. Naming Conventions and Definitions 6. Relevant Facts and Assumptions Functional Requirements 7. The Scope of the Work 8. The Scope of the Product 9. Functional and Data Requirements

8. Volere Template Overview (2) Non-functional Requirements 10. Look and Feel Requirements 11. Usability Requirements 12. Performance Requirements 13. Operational Requirements 14. Maintainability and Portability Requirements 15. Security Requirements 16. Cultural and Political Requirements 17. Legal Requirements

9. Volere Template Overview (3) Project Issues 18. Open Issues 19. Off-the-Shelf Solutions 20. New Problems 21. Tasks 22. Cutover 23. Risks 24. Costs 25. User Documentation and Training 26. Waiting Room 27. Ideas for Solutions

10. IEEE-1362 Template Developed by IEEE Presents a template that may be used to specify user requirements The template describes - current situation (without system) - justification for change (why new system) -description of proposed system (high level) IEEE Standard 1362-1998 Guide for Information Technology – System Definition – Concept of Operations Document

11. IEEE-1362 Template Overview (1) Title page Revision chart Preface Table of contents List of figures List of tables 1. Scope 1.1 Identification 1.2 Document overview 1.3 System overview 2. Referenced documents 3.Current system or situation 3.1 Background, objectives, and scope 3.2 Operational policies and constraints 3.3 Description of the current system or situation 3.4 Modes of operation for the current system or situation (e.g. active, maintenance, emergency) 3.5 User classes and other involved personnel 3.6 Support environment 4.Justification for and nature of changes 4.1 Justification of changes 4.2 Description of desired changes 4.3 Priorities among changes 4.4 Changes considered but not included

12. IEEE-1362 Template Overview (2) 5. Concepts for the proposed system 5.1 Background, objectives, and scope 5.2 Operational policies and constraints 5.3 Description of the proposed system 5.4 Modes of operation 5.5 User classes and other involved personnel 5.6 Support environment 6. Operational scenarios 7. Summary of impacts 7.1 Operational impacts 7.2 Organizational impacts 7.3 Impacts during development 8. Analysis of the proposed system 8.1 Summary of improvements (new capabilities, deleted capabilities, improved performance) 8.2 Disadvantages and limitations 8.3 Alternatives and trade-offs considered 9. Notes Appendices Glossary

13. Requirement Management with IEEE Standards Outline: 1.Is Requirements Management a solution to your problems? 2.Is Requirements Management a solution to your company’s most pressing problems? 3.IEEE Guidelines and Recommended Best Practices 4.Moving towards achieving CMMI compatibility 5.Summary and Conclusions 6.References

14. Is Requirements Management a solution to your problems?

15. Is Requirements Management a solution to your company’s most pressing problems?

16. Why Try IEEE? Customer’s standards reference the IEEE Standards The “Jumpstart CMM®/CMMI® Software Process Improvement Using IEEE Software Engineering Standards” maps the standards to CMMI® Templates in the standards make a framework for requirements to speed implementation. IEEE standards are a good benchmark to start at.

17. IEEE Guidelines and Recommended Best Practices IEEE Std 830TM - 1998, IEEE Recommended Practice for Software Requirements Specifications Sections Focused on 1. Introduction a. It should help… b. Should provide several specific benefits 2. Characteristics of a good SRS 3. Joint Preparation of the SRS 4. SRS Evolution 5. The parts of an SRS 6. ANNEX A SRS Templates IEEE Std 1233, 1998 Edition (R2002), IEEE Guide for Developing System Requirements Specifications Sections Overviewed 1. Introduction 2. Properties 3. Categorization 4. Techniques for identifying requirements

18. 1. Introduction, “It should help: a) Software customers to accurately describe what they wish to obtain. b) Software suppliers to understand exactly what the customer wants. c) Individuals to accomplish the following goals: 1) Develop a standard software requirements specification (SRS) outline for their own organizations; 2) Define the format and content of their specific software requirements specifications; 3) Develop additional local supporting items such as an SRS quality checklist, or an SRS writer’s handbook.” [IEEE Std 830-1998, p. iii]

19. 1. Introduction, “should provide several specific benefits. - Establish the basis for agreement between the customers and the suppliers on what the software product is to do. … - Reduce the development effort. … - Provide a basis for estimating costs and schedules. … - Provide a basis for validation and verification. … - Facilitate transfer. … - Serve as a basis for enhancement. … [IEEE Std 830-1998, p. iii]

20. 2. Characteristics of a Good SRS, “An SRS should be a) Correct; b) Unambiguous; c) Complete; d) Consistent; e) Ranked for importance and/or stability; f) Verifiable; g) Modifiable; h) Traceable. [IEEE Std 830-1998, p. 4]

21. 3. Joint Preparation of the SRS and 4. SRS Evolution 3. Joint Preparation of the SRS “... Customer and the supplier should work together to produce a well-written and completely understood SRS.” [IEEE Std 830-1998, p. 8] 4. SRS evolution “ A formal change process should be initiated to identify, control, track, and report projected changes.” [IEEE Std 830-1998, p. 9]

22. 5. The parts of an SRS 1. Introduction 2. Purpose 3. Scope 4. Definitions, Acronyms and Abbreviations 5. References 6. Overall Description 7. Product Perspective 8. Product Functions 9. User Characteristics 10. Constraints 11. Apportioning of requirements 12. Organizing the specific requirements. [IEEE Std 830-1998, pp. 11-18]

23. 6. ANNEX A SRS Templates The templates are for the specific requirements and include the following: a. System mode b. User class c. Objects d. Feature e. Stimulus f. Response g. Functional hierarchy [IEEE Std 830-1998, pp. 18-19]

24. Introduction “The purpose of this guide is to provide guidance for capturing system requirements. This guide serves the analyst by providing a clear definition for identifying well-formed requirements and ways of organizing them.” [IEEE Std 1233-1998 Edition (R2002), p. iii]

25. Properties “The collection of requirements should have the following properties: a) Unique set. … b) Normalized. … c) Linked set. … d) Complete. … e) Consistent. … f) Bounded. … g) Modifiable. … h) Configurable. … i) Granular. …” [IEEE Std 1233, 1998 Edition, p. 4]

26. Properties of a requirement “Each requirement should pos sess the following properties: a) Abstract. … b) Unambiguous. … c) Traceable. … d) Validate able. … [IEEE Std 1233, 1998 Edition, p. 12,13]

27. Categorization “the requirements should be categorized by their a) Identification. … b) Priority. … c) Criticality. … d) Feasibility. … e) Risk. … f) Source. … g) Type. … [IEEE Std 1233, 1998 Edition, p. 13]

28. Techniques for identifying requirements a) Structured workshops; b) Brainstorming or problem-solving sessions; c) Interviews; d) Surveys/questionnaires; e) Observation of work patterns (e.g., time and motion studies); f) Observation of the system’s organizational and polit ical environment (e.g., sociogram); g) Technical documentation review; h) Market analysis; i) Competitive system assessment; j) Reverse engineering; k) Simulations; l) Prototyping; m) Benchmarking processes and systems. [IEEE Std 1233, 1998 Edition, p. 16]

29. Matching up CMMI ® Processes and Goals to IEEE Land, S. K., JumpstartCMM®/CMMI® Software Process Improvement Using IEEE Software Engineering Standards, John Wiley & Sons, Inc. (p. 38)

30. Requirements Management Interactions Chrissis, M.B., Konrad, M. and Shru m S., CMMI Second Edition Guidelines for Process Integration and Product Improvement, Pearson Education, Inc. Boston, MA, Copyright 2007 (p. 82)

31. full IEEE set of software engineering documents IEEE 12207.2-1997 Industry Implementation of International Standard Document DeliverablesDescriptionActivities (IEEE/EIA 12207.2-1997) Software Project Management Plan (SPMP) Description of the software approach and associated milestones. System requirement analysis Software requirement analysis Software Requirements Specifications (SRS) Description of the expected software features, constraints, interfaces and other attributes. Process implementation Software Design Description (SDD) Description of how the software will meet the requirements. Also describes the rationale for design decisions taken. System architectural design Software architectural design Software detailed design Software Test Documentation (STD) Description of the plan and specifications to verify and validate the software and the results. Software qualification testing System qualification testing

32. purpose of each documents DocumentSummary of Purpose Software Project Management Plan (SPMP) To document the agreed deliverables and dates. Software Requirements Specifications (SRS) To document the agreed requirements with the project supervisor; to provide the basis for design; to provide the basis for system test Software Design Description (SDD) To document the design and design decisions in order to provide the basis for implementation and unit test Software Test Documentation (STD) To document how the software will be tested, and record the results.

33. Software Project Management Plan (SPMP) IEEE-1058(Standard for Software Project Management Plans), IEEE-1540 (Standard for Software Life Cycle Processes – Risk Management) Cover Page Revisions Page Table of Contents 1 INTRODUCTION 1.1 Project Overview 1.2 Project Deliverables 2 PROJECT ORGANIZATION 2.1 Software Process Model 2.2 Roles and Responsibilities 2.3 Tools and Techniques 3 PROJECT MANAGEMENT PLAN 3.1 Tasks 3.1.n Task-n 3.1.n.1 Description 3.1.n.2 Deliverables and Milestones 3.1.n.3 Resources Needed 3.1.n.4 Dependencies and Constraints 3.1.n.5 Risks and Contingencies 3.2 Assignments 3.3 Timetable 4 ADDITIONAL MATERIAL

34. Software Requirements Specifications (SRS) IEEE-830 (Recommended Practice for Software Requirements Specifications) IEEE Std 1233(Guide for Developing System Requirements Specifications) Cover Page Revisions Page Table of Contents 1 INTRODUCTION 1.1 Product Overview 2 SPECIFIC REQUIREMENTS 2.1 External Interface Requirements 2.1.1 User Interfaces 2.1.2 Hardware Interfaces 2.1.3 Software Interfaces 2.1.4 Communications Protocols 2.2 Software Product Features 2.3 Software System Attributes 2.3.1 Reliability 2.3.2 Availability 2.3.3 Security 2.3.4 Maintainability 2.3.5 Portability 2.3.6 Performance 2.4 Database Requirements 3 ADDITIONAL MATERIAL

35. Software Design Description (SDD) IEEE-1016 (IEEE Recommended Practice for Software Design Descriptions) Cover Page Revisions Page Table of Contents 1 INTRODUCTION 1.1 Design Overview 1.2 Requirements Traceability Matrix 2 SYSTEM ARCHITECTURAL DESIGN 2.1 Chosen System Architecture 2.2 Discussion of Alternative Designs 2.3 System Interface Description 3 DETAILED DESCRIPTION OF COMPONENTS 3.n Component-n 4 USER INTERFACE DESIGN 4.1 Description of the User Interface 4.1.1 Screen Images 4.1.2 Objects and Actions 5 ADDITIONAL MATERIAL

36. Software Test Documentation (STD) IEEE-829 (Standard for Software Test Documentation), IEEE-1008 (Standard for Software Unit Testing), IEEE-1012 (Standard for Software Verification and Validation) Cover Page Revisions Page Table of Contents 1 INTRODUCTION 1.1 System Overview 1.2 Test Approach 2 TEST PLAN 2.1 Features to be Tested 2.2 Features not to be Tested 2.3 Testing Tools and Environment 3 TEST CASES 3.n Case-n 3.n.1 Purpose 3.n.2 Inputs 3.n.3 Expected Outputs & Pass/Fail criteria 3.n.4 Test Procedure 4 ADDITIONAL MATERIAL (including appendix A) APPENDIX A. TEST LOGS A.n Log for test n A.n.1 Test Results A.n.2 Incident Report

37. Forming the IEEE 830 SRS Document from Use Cases

39. 2.1 Product perspective In Section 5.2.1 of IEEE 830 (Section 2.1 of the SRS), we are told that “this subsection of the SRS should put the product into perspective with other related products. … A block diagram showing the major components of the larger system, interconnect ions, and external interfaces can be helpful.” A use case diagram establishes the system boundary, and should show the use cases that provide functionality to actors outside the system boundary. To some extent this captures the interfaces needed for actors external to the system to interact with the system. Other sub­ systems could be represented as agents and the interaction with the system could still be captured just like for a regular actor.

40. 2.2 Product functions In Section 5.2.2 of IEEE 830 (Section 2.2 of the SRS), the major function s that the system will perform are described in summary form. IEEE 830 offers no guidance on how to organize descriptions of the major functions (although several suggestions on organizing the mo re detailed functional requirements are included). One of the classifications mentioned above, that of primary vs. second ary vs. optional use cases, can be used to narrow down the field of the possible use cases so that only primary use cases would be described in the major function summary section. The field can further be narrowed by applying the core vs. Administrative vs. routine use case classification scheme to eliminate primary admi nistrative and routine use cases. What is left are only the primary co re use cases.

41. 2.3 User characteristics Section 2.3 of the SRS describes “general characteristics of the intended users of the product…” In the Use Case m odel an actor is a role. However, IEEE 830 asks for information about the backgrounds of the intended users, including “educational level, experience, and technical expertise,” and these have no corresponding collection point within the Use Case, so will have to be added separately. But, mapping roles to users may aid the discovery process.

42. 2.4 Constraints Constraints, included in Section 2.4 of the SRS, are “items that will limit the developer’s options” (IEEE 830). Constraints are also sometimes called non­ functional requirements because they are requirements that t he system must meet, yet they do not provide or describe fun ctionality that accomplishes the purpose of the system. Examples include regulatory compliance requirements, p erformance requirements, and compatibility with externally specified protocols and system interfaces. Representation of non­ functional requirements is topic of research but, presently it is included as business rules governing the interaction.

43. 2.5 Assumptions and dependencies Assumptions and dependencies (Section 2.5 of the SRS) come fro m several places in the usecase­based specification process. Some assumptions are stated in the preconditions of the functi onal use cases, particularly when the preconditions refer to thi ngs external to the system, whether they are actors or external systems.

44. 2.6 Apportioning of requirements Section 2.6 of the SRS document should “identify requirements that may be delayed until future versions of the system.” This information is identified by the primary vs. Secondary vs. Optional use case categorization described in Goldman and Song (2005). Goldman, J. and Song, I. (2005). “Organizing and Managing Use Cases,” in the First International Workshop on B est Practices of UML, Oct. 26­28, 2005, Klagenfurt, Austria, (in Perspectives in Conceptual Modeling, LNCS Vol. 3770, Editor: J. Akoka, etc. Springer Verlag, 2005), pp. 43­52

45. 3. Specific Requirements Section 3 of the SRS document contains the heart of the specifica tion of exactly what the system should do and how. Section 3 r evisits some of the areas that were addressed in Section 2, bu t suggests that this is the appropriate place for inclusion of a h igher level of detail. Therefore, essential and business use ca ses are not appropriate for translation into Section 3, only real system use cases are.

46. 3.1 External interfaces The external interfaces described for inclusion 3.1 are a more detailed descrip tion of the interfaces mentioned in Section 2.1 of the SRS documen t. The appropriate place to find the corresponding information is in t he narrative description of the use case primary and alternative scenarios. These are typically described in a request­and­ response format, where an actor action is followed by one or more system responses, followed by further actor actions and system r esponses, until the completion of the use case and the satisfaction of the r equirement. The set of all actor actions, and corresponding system respon ses, ought to suffice as “a detailed description of all inputs into and output s from the software system.” (IEEE 830, p. 16)

47. Customer’s Bills of Rights and Responsibilities Developed by Karl E. Weigers for his book, Software Requirements “Delineates what customer should expect from project team “Clarifies what customer needs to provide to project team

48. Customer Bill of Rights 1.Expect analysts to speak your language. 2.Expect analysts to learn about your business and your objectives. 3.Expect analysts to structure the information you present into a written software requirement specification. 4.Have developers explain all work products created from the requirements process. 5.Expect respect, collaboration, and professionalism from developers. 6.Have developers provide you with ideas and alternatives both for your requirements and for implementation of the product. 7.Describe characteristics of the product that will make it easy and enjoyable to use. 8.Be presented with opportunities to adjust your requirements to permit reuse of existing software components. 9.Be given good-faith estimates of cost, impacts, and trade-offs when you request a change in the requirements. 10.Receive a system that meets your functional and quality needs, based on mutually agreed-upon needs.

49. Customer Bill of Responsibilities 1.Educate analysts about your business and define business jargon. 2.Spend the time it takes to provide requirements, clarify them, and iteratively flesh them out. 3.Be specific and precise when providing input about the system’s requirements. 4.Make timely decisions about requirements when requested to do so. 5.Respect a developer’s assessment of the cost and feasibility of requirements. 6.Set priorities for individual requirements, system features, or use cases 7.Review requirements documents and prototypes. 8.Communicate changes to the project requirements as soon as you know about them. 9.Follow the development organization’s defined process for requesting requirements changes. 10.Respect the processes the developers use for requirements engineering.