Transcript requirements management

Notes of Using RequisitePro
cyt
• 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.”
2
• To find out what the requirements are, write them down, organize
them, and track them in the event they change.
3
• 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.
4
•
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.
5
• 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
6
•
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.
7
8
•
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.
9
• 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.
10
11
• 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.
12
•
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.
13
• 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.
14
•
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.
15
16
17
•
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.
18
•
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.
19
•
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.
20
• 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
•
21
22
23
24
25
26
27
28
29
30
31
32