Notes of Using RequisitePro

1. Notes of Using RequisitePro cyt

2. Type of user • Requirements viewers • Requirements contributors • Requirements authors • Project administrator • Rational defines a requirement as “a condition or capability to which the system [being built] must conform.” The Institute of Electronics and Electrical Engineers (IEEE) uses a similar definition. • Failing to manage requirements decreases the probability of meeting these objectives. Recent evidence is supportive: • The Standish Group’s CHAOS Reports from 1994, 1997, and 2000 established that the most significant contributors to project failure relate to requirements. • In December 1997, Computer Industry Daily reported on a Sequent Computer Systems, Inc., study of 500 IT managers in the U.S. and U.K. that found 76 percent of the respondents had experienced complete project failure during their careers. The most frequently named cause of project failure was “changing user requirements.”

3. To find out what the requirements are, write them down, organize them, and track them in the event they change.

4. Stated another way, requirements management is: • a systematic approach to eliciting, organizing, and documenting the requirements of the system, and • a process that establishes and maintains agreement between the customer and the project team on the changing requirements of the system.

5. Requirements are not always obvious and have many sources. • Requirements are not always easy to express clearly in words. • Many different types of requirements at different levels of detail must be managed. • The number of requirements can become unmanageable if not controlled. • Requirements are related to one another and to other deliverables of the process in a variety of ways. • Many interested and responsible parties are involved in a project, which means that requirements must be managed by cross-functional groups of people. • Requirements change. • Requirements can be time-sensitive.

6. Rational RequisitePro is an accessible tool for automating effective requirements management. • Requirements Managements skills • Analyze the Problem • Understand Stakeholder Needs • Define the System • Manage the Scope of the Project • Refine the System Definition • Manage Changing Requirements

7. To define the system means to translate and organize the understanding of stakeholder needs into a meaningful description of the system to be built. • The scope of a project is defined by the set of requirements allocated to it. • Managing scope is a continuous activity that requires iterative or incremental development, which breaks project scope into smaller, more manageable pieces. • Refining the system definition includes two key considerations: developing more detailed descriptions of the high-level system definition and verifying that the system will comply with stakeholder needs and behave as described. • Managing requirement change includes activities such as establishing a baseline, keeping track of the history of each requirement, determining which dependencies are important to trace, establishing traceable relationships between related items, and maintaining version control.

9. Usually, one type of requirement can be broken down, or decomposed, into other types. • Business rules and vision statements can be types of high-level requirements from which teams derive user needs, features, and product requirement types. • Use cases and other forms of modeling drive design requirements that can be decomposed to software requirements and represented in analysis and design models. • Test requirements are derived from the software requirements and decompose to specific test procedures. • Requirements teams should also include those who create the system solution—engineers, architects, designers, programmers, quality assurance personnel, technical writers, and other technical contributors.

10. In order for teams to determine the impact of changes and feel confident that the system conforms to expectations, these traceability relationships must be understood, documented, and maintained.

12. Effective requirements management includes the following project team activities: • 1 Agree on a common vocabulary for the project. • 2 Develop a vision of the system that describes the problem to be solved by the system, as well as its primary features. • 3 Elicit stakeholders’ needs in at least five important areas: functionality, usability, reliability, performance, and supportability. • 4 Determine what requirement types to use. • 5 Select attributes and values for each requirement type. • 6 Choose the formats in which requirements are described. • 7 Identify team members who will author, contribute to, or simply view one or more types of requirements. • 8 Decide what traceability is needed. • 9 Establish a procedure to propose, review, and resolve changes to requirements. • 10 Develop a mechanism to track requirement history. • 11 Create progress and status reports for team members and management.

13. RequisitePro helps projects succeed by giving teams the ability to manage all project requirements comprehensively and facilitating team collaboration and communication. • RequisitePro combines both document-centric and database-centric approaches. • By deeply integrating Microsoft Word with a multi-user database, RequisitePro lets you organize, prioritize, trace relationships, and easily track changes to your requirements. • The program’s unique architecture and dynamic links make it possible for you to move easily between the requirements in the database and their presentation in Word documents. • Requirements drive the entire project. • RequisitePro’s integration with other industry-leading tools optimizes the flow of requirements data throughout the project, promoting consistency and ensuring that what is designed, tested, documented, and delivered meets the users’ needs. • RequisitePro’s deep integration with other lifecycle tools promotes artifact reusability and eases the sharing of information, further enhancing team collaboration.

14. In addition to the Windows client version of RequisitePro, RequisiteWeb offers a Web-based client for RequisitePro. RequisiteWeb allows users to access RequisitePro requirements information across an intranet. • RequisiteWeb provides a thin client solution to access project documents and data. • Using RequisiteWeb, you can modify the name, text, and attributes of requirements directly in the database and from within documents, and you can create, delete, and query requirements and assign new parents to them. • Requirement authoring through the Web allows better support of distributed teams and multiple-platform environments. • For each requirement a change history is maintained, capturing the who, what, when, and why of the change.

15. RequisiteWeb supports the following features: • Viewing documents • Modifying requirements (in documents or database) • Creating requirements in the database • Creating and modifying Attribute Matrix views • Creating and modifying Traceability Tree views (traced into or traced out of) • Setting your own user password • Viewing, modifying, and creating hierarchical relationships • Creating traceability links within and across projects • Filtering and sorting requirements • Creating and replying to discussions • A RequisitePro project includes a requirements database and its related documents. • The project database is the requirements database managed by RequisitePro. When you use RequisitePro, you can use one of three physical databases to store requirements: Microsoft Access, Oracle, or Microsoft SQL Server.

18. A requirements document is a specification that captures requirements, describes the objectives and goals of the project, and communicates product development efforts. • Each requirements document belongs to a particular document type. • RequisitePro manages requirements directly in the project documents. When you build a requirements document, RequisitePro dynamically links it to a database, which allows rapid updating of information between documents and views. When you save revisions, they are available to team members and others involved with the project. • Hierarchical requirement relationships are one-to-one or one-to-many, parent-child relationships between requirements of the same type. • Use hierarchical relationships to subdivide a general requirement into more explicit requirements. • Traceability links requirements to related requirements of same or different types. • Without traceability, each change would require a review of your documents to determine which, if any, elements need updating. • Traceability relationships cannot have circular references. • The trace to/trace from state represents a bidirectional dependency relationship between two requirements.

19. feature requirement (Requirement A) and use-case requirement (Requirement B) • A is traced to B • B is traced from A • Traceability relationships may be either direct or indirect. • A hierarchical relationship or a traceability relationship between requirements becomes suspect if RequisitePro detects that a requirement has been modified. • If a requirement is modified, all its immediate children and all direct relationships traced to and from it are suspect. • When you make a change to a requirement, the suspect state is displayed in a Traceability Matrix or a Traceability Tree. • Rational RequisitePro views use tables or outline trees to display requirements and their attributes or the traceability relationships between different requirement types. • After you have created a view, you can save it as is, or you can refine the view by querying (filtering and sorting) its information in a variety of ways.

20. Discussions let you address comments, issues, and questions to a group of participants that you define. Discussions can be associated with one or more specific requirements, or they can refer to the project in general. A discussion item is either the initial discussion topic or a response. A participant can respond to either the initial discussion text or to another response. • A requirement describes a condition or capability that a system must provide; it is either derived directly from user needs or is stated in a contract, standard, specification, or other formally imposed document. Examples of requirements include inputs to the system, outputs from the system, and functions and attributes of the system and the system environment. • Requirements may be described in terms of the “FURPS” model, which categorizes the major types of requirements as follows: • Functional requirements: feature sets, capabilities, and security. • Usability requirements: human factors, aesthetics, consistency in the user interface, online and context-sensitive help, wizards and agents, user documentation, and training materials. • Reliability requirements: frequency and severity of failure, recoverability, predictability, accuracy, mean time between failure. • Performance requirements: conditions imposed on functional requirements. • Supportability requirements: testability, extensibility, adaptability, maintainability, compatibility, configurability, serviceability, installability, and localizability.

21. Each project includes the following: a database, documents, packages, document types, requirements, requirement types, attributes, attribute values, discussions, traceability relationships, saved personal and project wide views, revision histories, and security information. • After you create a RequisitePro project based on one of these three templates • Use-Case Template • Traditional Template • Composite Template