REQUIREMENTS TRACEABILITY MATRIX

 The purpose of the RTM is to help ensure the object of the requirements conforms
to the requirements by associating each requirement with the object via the
traceability matrix.
 A traceability matrix is used to verify that all stated and derived requirements are
allocated to system components and other deliverables (forward trace).

 The matrix is also used to determine the source of requirements (backward trace).
Requirements traceability includes tracing to things other than software that
satisfy the requirements such as capabilities, design elements, manual operations,
tests, etc.
 The traceability matrix is also used to ensure all requirements are met and to
locate affected system components when there is a requirements change. The
ability to locate affected components allows the impact of requirements changes
on the system to be determined, facilitating cost, benefit, and schedule
determinations.

Traceability Strategy

 The extent of the RTM depends on what will be managed. Considerations include
contractual requirements, risk, and overhead costs relative to the budget. The
traceability strategy is devised by graphing relationships between work products.
Conduct a proof of concept for your strategy using your selected RM tool.
 Software is developed in stages, each with work products that can be associated
with work products of the previous stage, creating the ability to trace from the
requirements through the work products and from the work products back to the
requirements. What work products are required depends on the organization's
standards and development practices. In general:

 The need (requirement) for a new system or modification to the current system is
identified. The need is analyzed to further define the requirement.
 A feasibility study should be performed to answer questions in more detail such
as: what needs to be done, what is the value of doing it, what business goals are
supported, how it can be done, what are the alternatives, and what are the risks.
The results are documented in a business case. Requirements at this stage are
insufficiently detailed to build or modify a system.

 A project may then be initiated based on the selected alternative from the business
case. Ideally, the requirements traceability matrix (RTM) is started now. The high
level requirements are linked to the business goals. As work products are created
throughout development, the RTM will be updated to provide full traceability.

 An Operations Concept document may be created to convey uses of the system

and to set the system and project boundaries. A top-level architecture document
may also be developed.

 System functional requirements are documented in three phases: identification,

analysis, and baseline establishment.

 During the identification phase, the developer/maintainer reviews the documents

provided by the customer to identify the specific system functional and
performance groups into which the requirements fall. The requirements may be
further categorized into subgroups. Interviews, prototyping, and a variety of
techniques may be used to identify requirements.

 The requirements are analyzed to ensure they are complete, consistent, testable,
and feasible within budget and technical constraints. The requirements are also
reviewed to eliminate redundancy. Acceptance criteria for each requirement are
developed. A draft system specification is produced.

 After approval, the requirements and associated documentation are formalized as

the functional baseline.

 Design, code, test, manuals, and other work products are developed in accordance
with the requirements. As they are developed, work products in the functional
baseline may be updated or modified in accordance with the organization's
configuration management process. Traceability is used throughout to verify that
goals and requirements are being met.

 Traceability matrices can be established using a variety of tools including

requirements management software, databases, spreadsheets, or even with tables
or hyperlinks in a word processor.
 Above is a simple traceability matrix
structure. There can be more things included in a traceability matrix than shown. In
traceability, the relationship of driver to satisfier can be one-to-one, one-to-many, many-
to-one, or many-to-many.

Traceability requires unique identifiers for each requirement and product. Numbers for
products are established in a configuration management (CM) plan.

Traceability ensures completeness, that all lower level requirements come from higher
level requirements, and that all higher level requirements are allocated to lower level
requirements. Traceability is also used to manage change and provides the basis for test
planning.

Sample Traceability Matrix -The examples show forward and backward tracing
between user and system requirements. User requirement identifiers begin with "U" and
system requirements with "S." Tracing S12 to its source makes it clear this requirement is
erroneous: it must be eliminated, rewritten, or the traceability corrected.
For requirements tracing and resulting reports to work, the requirements must be of good
quality. Requirements of poor quality transfer work to subsequent phases of the SDLC,
increasing cost and schedule and creating disputes with the customer

A variety of reports are necessary to manage requirements. Reporting needs should be

determined at the start of the effort and documented in the requirements management
plan.

Traceability Template

1. Business Requirement No.

2. Priority(High, Medium, Low)

3. Requirement Type (Enhancement, Change Request)

4. Business Requirement Description

5. Feature or Module Name

6. Source Code Reference (Path & Name)

7. Unit test Case Path & Name

8. Integration/System Test Case Path & Name

9. Open Defects

10. Closed Defects

REQUIREMENT MANAGEMENT REPORTS - Some examples of requirements

management reports are below. When identifying requirements management information
needs for your project, provide an example of suggested reports. This will help you get
better feedback on what kinds on information to keep in the requirements repository.
Reports are based on the information associated with the requirements. (Requirement text
can be omitted from some reports, but is included in the examples for clarity.)

 Backward trace: a traceability report showing the origin of an item. This

can be used to determine if unnecessary items are being created (gold
plating) that are not warranted by the requirements or to discover the
reason for an item.
 Compliance matrix: a report showing the requirements that have been
satisfied by a work product or activity.

 Forward trace: a traceability report showing items that would be affected

by a requirements change, such as the impact on a design, documents,
and/or software.
  Priority: a report of requirements by priority. This report may be used to
determine what requirements must be implemented before others. It is also
useful when time to build is inadequate or funding is limited.

 Qualification method: a report of requirements by qualification method

(inspection, analysis, demonstration, test). This report provides
requirements that testers or others must address.

 Requirements validation matrix: a report of requirements and the test

cases associated with them. The report can be used to track test case
development and approval and can be included in the master test plan.

 Risk: a report of requirements by risk level. This report may be used to

determine what requirements are most critical to test completely or to
assist in planning when time to test is inadequate.

 Unsatisfied/unallocated requirements: a report of requirements those are

unaddressed or unassigned. This report may accompany a compliance
matrix and is a quality check to ensure no requirement has been dropped.

Habits of an Effective Analyst

Habit #1: Seek First to Understand, Then to be understood.

 The analyst is a communication middleman, bridging the gap between vague

customer notions and clear developer specifications.
 The analyst must first understand the user’s actual needs and then define a set of
functional requirements and quality goals that allow designers, implementers and
testers to build and verify the system.

 If you aspire to be an effective analyst, become proficient in all forms of

communication, including listening, speaking and writing.

 As you interact with executive project sponsors, marketing and user

representatives, understand their objectives for the proposed system and their
concerns about the business and the application.

 Learn and use the vocabulary of the application domain, rather than forcing your
customers to understand computer jargon.

 Include business terms in a project glossary, which should become part of the
requirements documentation.

 Focus discussions with users on the tasks they must perform with the systems and
their use cases.

 Ask for examples of likely user goals, which will serve as the starting point for
capturing scenarios you can use to develop accurate functional requirements.
  Don’t be afraid to ask for clarification; customers shouldn’t expect every analyst
to be an application domain expert.

 You might explain that you are not completely familiar with the customers
business and that is why you don’t fully grasp what they are describing. This
approach sometimes makes customers more willing to help because they can see
that you are making a real effort to understand their problems.

 The analyst is responsible for writing high-quality and well-organized

requirements documents that clearly express this shared understanding.

 Writing documents that customer representatives can understand and verify, while
un-ambiguously conveying precise functional and nonfunctional requirements to
the developers, is a tightrope walk. A single requirements document might not
meet both needs

Habit #2: Begin with the End in Mind.

 Most projects that suffer from scope creep do so because the intended scope, the
boundary between what is in and what is out, was never documented.
 Begin your exploration of new systems requirements by defining the ultimate
vision of what the product or application will be and do.

 Engage in a dialogue with the projects funding sponsor, marketing manager or

product visionary early on to define the projects business requirements.

 You might suggest a suitable template for a vision and scope document or a
marketing requirements document and work with those who hold the vision to
help them describe it.

 Because the team probably won’t implement the end result right off the bat,
define the scope of the first release as a subset of the final product.

 Describe a growth path from the initial release toward realizing the ultimate
vision through a series of staged releases.

 Another aspect of beginning with the end in mind is to focus the early
requirements discussions on the tasks users need to accomplish with the system.

 An understanding of user goals leads to the necessary functional requirements,

which then leads to detailed user interface design.

Habit #3: Be Proactive.

  When working as an analyst, you’ll need to actively facilitate discussions with
users to pull out information that might otherwise go unstated.
 Ask questions to identify possible alternative ways a user might want to perform
some task and related tasks that the user representatives didn’t mention initially.

 Users naturally focus on the systems normal, expected behaviors.

 However, much code gets written to handle exceptions, so you should also search
for possible error conditions that could arise and decide how the system should
respond.

 If you don’t describe exceptions during requirements elicitation, the developers

will either make their best guess at how to handle them, or the system will simply
fail when a user hits the error condition. It’s a safe bet that system crashes aren’t
in the users plans.

 Sometimes users don’t fully appreciate the capabilities that developers could
provide, and they get excited when you suggest functionality that will really make
the system useful. When users truly can’t express what they need, perhaps you
can watch them work and suggest ways to automate appropriate portions of the
job.

 Analysts can often think out of the box that limits the creativity of people who are
too close to the problem being solved. And be careful to avoid gold-plating. Don’t
add extra functionality that just seems cool.

 Look for opportunities to reuse functionality that is already available in another

system. Users can sometimes adjust their requirements to exploit such reuse
possibilities if the benefit is faster delivery of close-enough functionality that is
already road-tested.

 To function as an effective analyst, you must think at multiple levels of

abstraction. You should be able to generalize from a specific need expressed by
one user representative to define a set of related needs that will satisfy many
members of that individual user class.

Habit #4: Put First Things First.

 Requirements development is an iterative and incremental process, proceeding

from fuzzy notions to detailed specifications a layer at a time.
 If you are facilitating an elicitation workshop, keep the discussion focused on the
right level of abstraction for those days’ objectives. Don’t let the participants get
bogged down in excessive detail or premature system design. While it can be
valuable to sketch out possible user interface screens or build prototypes to clarify
the requirements, diving deeply into design too early can lead to a system that
fails to meet the user’s actual needs.
  It’s discouraging to realize at crunch-time that everything the team has left to do
is essential, while they have already implemented some features that weren’t
really that important.

 Analysts must work with customers to define the priorities for requested product
features, so the team can build the most critical functionality first. All customers
will claim that their requirements should have the top priority.

Habit #5: Think Win/Win.

 Software development is often characterized by strained relationships among

developers, users, managers and marketing. The parties may not trust each others
motivations or appreciate each others needs and constraints.
 A win/win outcome means customers are delighted with the product, the
developing organization is happy with the business outcomes, and the
development team members are proud of the good work they did on a challenging
and rewarding project.

 Achieving a win/win outcome requires honesty. Sharing all relevant information

among the stakeholders and telling the truth without blame or judgment promotes
free and informed choices. Such an ideal environment isn’t always achievable.

 Defining business requirements early in the project will clarify the prospective
benefits for both customers and the developing organization.

 The participants also need to be honest about functionality costs and project
constraints. If you think the customers cost or schedule expectations are
unrealistic, tell them so and explain your reasoning.

 Considering the costs will help the stakeholders make sensible business decisions
to achieve the maximum value within the existing resource, time and technology
constraints.

 It’s not unusual for an analyst to solicit input from users only to be told, "I don’t
have time to talk to you. You should know what I need." However, software
success is most likely to occur when the analyst can forge an effective
collaborative relationship with key customer representatives

 User representatives might hesitate to participate in requirements exploration until

they know exactly what you expect from them. Write down the contributions you
would like to get from your customer collaborators and negotiate an appropriate
level of commitment from each one.

 The vision and scope document will help you identify the right users to talk to. It
also gives the user representatives a clear understanding of what the project is
trying to achieve.
  Insufficient user involvement is well established as a leading cause of software
project failure. Point this out to recalcitrant users or managers who don’t want to
spend time on requirements discussions.

 Remind your customers of problems they have experienced on previous projects

that can be attributed to inadequate user involvement. Nearly every organization
has horror stories of new systems that didn’t satisfy user needs, failed to meet
unstated usability or performance expectations, or duplicated the shortcomings of
the preceding systems.

 You can’t afford to keep rebuilding or discarding systems that don’t measure up
because the user’s needs weren’t sufficiently understood.

Habit #6: Hone Your Skills. - The requirements analyst provides the essential function
of bridging the understanding and perspective gap that lies between customers and
developers. A competent analyst must combine communication, facilitation and
interpersonal skills with some technical and business domain knowledge. The following
capabilities are particularly important:

 Facilitation techniques, to lead elicitation workshops;

 Interviewing techniques, to talk with individuals and groups about their needs;

 Listening skills, to understand what people say and to detect what they might be
hesitant to say;

 Writing skills, to communicate information effectively to users, managers and

technical staff;

 Organizational skills, to make sense of the vast array of information gathered

during elicitation and analysis;

 Interpersonal skills, to help negotiate priorities and resolve conflicts among

project stakeholders;

 Domain knowledge, to have credibility with user representatives and converse

effectively with them; and

 Modeling skills, to represent requirements information in graphical forms that

augment textual representations in natural language.

Requirements for a software product aren’t just lying around waiting for someone
wearing a hat labeled "analyst" to collect them. At best, requirements exist in the minds
of users, visionaries and developers, from which they must be gently extracted and
massaged into a usable form. Often, they need to be discovered with guidance from a
talented analyst, who helps users understand what they really need to meet their business
needs and helps developers satisfy those needs. Few project roles are more difficult than
that of requirements analyst. Few are more critical.

GAP ANALYSIS

CONFIGURATION MANAGEMENT

CM establishes and maintains the integrity of work products throughout their life.
Elements of CM include:

CM plan

 Change coordination
 Configuration identification

 Configuration control

 Configuration status accounting

 Configuration auditing.

CM plans establish and document the requirements, standards, practices, and procedures
for configuration management. This includes defining baselines and establishing the
labeling scheme for configuration items.
A baseline is a group of configuration items (products, deliverables) developed during a
specific phase of the development process that has been formally accepted. Once the
baseline is established, changes to the items can only be done through a formal change
process. There are five baselines typically used in system development: functional,
allocated, design, product, and operational. The functional baseline may contain an initial
investigation baseline, a feasibility study baseline, and a requirements definition baseline.

Ex: High Level Configuration Management

Change Control - Change control is the process for incorporating changes to the product
and project. The change control process ensures that changes are authorized, documented,
and coordinated.

Version Description Documentation

Changes or enhancements are periodically incorporated into software and released as new
versions or interim changes. Version description documentation (VDD) is prepared to
describe new versions and interim changes to the software. The VDD documents:

 Differences between the versions

 Capabilities of the version

 Effects on software operations caused by the new version

 Other information such as how to install the software and known errors

The first phase in the cycle is the execution of a risk assessment. The objectives of the
assessment are to:

 Identify critical information assets

 Discover possible threats to the identified assets
  Identify vulnerabilities to the discovered threats and the associated probability of
exploitation

 Calculate the risk associated with each asset

 Risk can be evaluated using either a quantitative or a qualitative approach.

Quantitative assessments use actual dollar amounts to provide a financially-based
risk value. Qualitative assessments use scoring methods and the experience of
employees and consultants to arrive at a risk score.

Risk Management

Risk management is about identifying risk, assessing the impact on your business if a
security incident occurs, and making the right financial decision about how to deal with
the results of your assessment. It also includes the implementation of a program to
continually measure and assess the effectiveness of existing safeguards in protecting your
critical assets. Managing risk is not a one-time activity; it’s an ongoing process.

The quantitative approach is easier to present to

executive management because it deals with actual numbers. However, it is very
resource intensive. Attempting to calculate actual dollar values for business impact is
difficult, if not impossible in many cases. A qualitative assessment is easier to perform,
and although it might not provide hard dollar amounts, it should get you “close enough”.

Determining how to manage the identified risk is next. After you’ve calculated risk
scores, they should be sorted from highest to lowest. This allows you to address the
highest risks to your information assets first. There are essentially four ways to deal with
each risk:

 Reject the Risk – Rejecting risk is the head-in-the-sand approach. Some

managers tend to ignore difficult challenges with the hope that they will simply
disappear. This approach will rarely result in a successful defense against
security incidents.
 Accept the Risk – A common action to take is to accept the stated risk. For
example, if the controls necessary to eliminate or mitigate key vulnerabilities are
 a greater financial burden than the actual risk impact, then it’s probably a good
idea to use the security budget dollars in other areas.

 Transfer the Risk – An alternative to accepting higher than reasonable risk when
the cost of controls is too high is to purchase insurance to lower the business
impact of an incident. This is also a common risk management step.

 Mitigate the Risk – Risk mitigation typically focuses on vulnerability

management. The reasonable and appropriate implementation of administrative,
technical, and physical controls can serve to significantly reduce business risk.

Project Scope Management - Project Scope Management is a group of processes

required to ensure that the project includes all the work required, and only the work
required, to complete the project.

Processes

There are following processes which are part of Project Scope Management.

 Scope Planning
 Scope Definition

 Create WBS (Work Breakdown Structure)

 Scope Verification

 Scope Control

The term "Scope" may refer to

 Product Scope: The features and functions that are to be included in a product or
service.

 Project Scope: The work that must be done in order to deliver a product with the
specified features and functions.