Rekayasa Kebutuhan Perangkat Lunak - Share ITS

Rekayasa Kebutuhan Perangkat Lunak - Share ITS

Rekayasa Kebutuhan Perangkat Lunak Requirements Document Standards 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) 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 Requirements Document Standards/Templates

- System context - What should the system do! Nonfunctional requirements specified in user doc. Cost and Effort Information

Risk Functional requirements - Constraints Standards Project Information -

specified in user doc. (sometimes refined in developer doc.) Organizational requirements - Business Processes Stakeholders Rationale (Why is the software developed)

How good should the system do its job. specified at high level in user doc. refined in developer doc. 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: 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 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 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 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

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 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 Requirement Management with IEEE Standards Outline:

1. Is Requirements Management a solution to your problems? 2. Is Requirements Management a solution to your companys most pressing problems? 3. IEEE Guidelines and Recommended Best Practices 4. Moving towards achieving CMMI compatibility 5. Summary and Conclusions 6. References Is Requirements Management a solution to your problems? Is Requirements Management a solution to your companys most pressing problems?

Why Try IEEE? Customers 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. 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

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 writers handbook. [IEEE Std 830-1998, p. iii] 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] 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] 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]

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]

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] 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] 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] 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] 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] 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 systems 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] 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) 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) full IEEE set of software engineering documents IEEE 12207.2-1997 Industry Implementation of International Standard Document Deliverables Software Project Management Plan (SPMP) Software Requirements Specifications (SRS)

Software Design Description (SDD) Software Test Documentation (STD) Description Description of the software approach and associated milestones. Description of the expected software features, constraints, interfaces and other attributes. Description of how the software

will meet the requirements. Also describes the rationale for design decisions taken. Description of the plan and specifications to verify and validate the software and the results. Activities (IEEE/EIA 12207.2-1997) System requirement analysis Software requirement analysis Process implementation System architectural design

Software architectural design Software detailed design Software qualification testing System qualification testing purpose of each documents Document Summary of Purpose Software Project Management Plan To document the agreed deliverables and dates. (SPMP) Software Requirements Specifications To document the agreed requirements with the (SRS) project supervisor; to provide the basis for design; to provide the basis for system test

Software Design Description To document the design and design decisions in (SDD) order to provide the basis for implementation and unit test Software Test Documentation To document how the software will be tested, and (STD) record the results. 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 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 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 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 Forming the IEEE 830 SRS Document from Use Cases Forming the IEEE 830 SRS Document from Use Cases

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, interconnec tions, 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. 2.2 Product functions In Section 5.2.2 of IEEE 830 (Section 2.2 of the SRS), the major functions 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 more detai led functional requirements are included). One of the classifications mentioned above, that of primary vs. secondary 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 administrati ve and routine use cases. What is left are only the primary core use cases. 2.3 User characteristics

Section 2.3 of the SRS describes general characteristics of the intended users of the product In the Use Case model an actor is a role. Howe ver, 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.

2.4 Constraints Constraints, included in Section 2.4 of the SRS, are items that will limit the developers 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, performance 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.

2.5 Assumptions and dependencies Assumptions and dependencies (Section 2.5 of the SRS) come fro m several places in the usecasebased 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. 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. 2628, 2005, Klagenfurt, Austria, (in Perspectives in Conceptual Modeling, LNCS Vol. 3770, Editor: J. Akoka, etc. Springer Verlag, 2005), pp. 4352 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 cases are not appropriate for translation into Section 3, only real system use cases are. 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 document. The appropriate place to find the corresponding information is in the narrative description of the use ca se primary and alternative scenarios. These are typically described in a req uestandresponse format, where an actor action is followed by one or more system responses, followed by further actor actions and system responses, until the completion of the use case and the satisfactio n of the requirement. The set of all actor actions, and corresponding syste m responses, ought to suffice as a detailed description of all inputs into a nd outputs from the software system. (IEEE 830, p. 16) Customers 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 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. 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 systems requirements. 4. Make timely decisions about requirements when requested to do so. 5. Respect a developers 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 organizations defined process for requesting requirements changes. 10.Respect the processes the developers use for requirements engineering.

Recently Viewed Presentations

  • ECHO -

    ECHO -

    Life EMS is an ambulance company. TANDEM365. Community & Provider Partnerships-Working with other health providers-Engaging with the community regarding . supportive services . Four partners are Retirement Communities that have been in existence for many years. Two of them are...
  • Alternatives to 3He for Neutron Detection James Ely1

    Alternatives to 3He for Neutron Detection James Ely1

    Of the currently available neutron detection technologies, BF 3-filled proportional detectors, boron-lined proportional detectors, 6Li-loaded scintillating glass fiber, or non-scintillating coated plastic fiber detectors are the possible replacements for 3He detector technology—if they are proven to have appropriate capabilities. This...
  • The Saga of Tony Leone -

    The Saga of Tony Leone -

    The work of building an athletic program is officially under way. Hallowed ground The ideal location for a memorial recognizing his undying generosity and caring for a fledgling program that only existed because of his efforts.
  • Apresentação do PowerPoint

    Apresentação do PowerPoint

    * 1845 Jean Antoine Théodore de Gudin Obra de imaginação, executada no século XIX, pintada pelo artista francês Jean Antoine Théodore de Gudin, e gravada por Chavane (buril, colorido a mão). Théodore de Gudin, nome pelo qual era mais conhecido,...
  • Chapter 5 Gases - Kent City School District

    Chapter 5 Gases - Kent City School District

    3) Secondary structure arises as a polypeptide chain twists into a helix (coil), loop, or sheet held in place by hydrogen bonds. 4) Tertiary structure arises when loops, helices, and sheets fold up into a domain. In this example, the...
  • Acids and Alkalis - Physicslocker

    Acids and Alkalis - Physicslocker

    In the 1940s, an Englishman called John Haigh murdered six people, and disposed of each of the bodies by dissolving them in sulfuric acid for two days. Without the bodies as evidence Haigh thought he would get away with the...

    Lucy Stone. Images courtesy of Library of Congress. Sojourner Truth. Susan B. Anthony. Frederick Douglass. William Lloyd Garrison. Leading Utah Suffragists. Emmeline B. Wells. Dr. Martha Hughes Cannon. The left cartoon bears the caption: "An Unsightly Object—Who Will Take an...
  • SIA326: Identity and Access Management: Single Sign-on Across ...

    SIA326: Identity and Access Management: Single Sign-on Across ...

    Identity and Access Management: Single Sign-on Across Organizations and the Cloud - Active Directory Federation Services 2.0 Architecture Drilldown ... Intranet Client . Attribute Stores. AD FS 2.0 Components. ... RPs and CPs. Requires encryption certificate. HTTP POST Requests.