Executive in wait

INCOSE Requirements Management Tools Survey September 13, 2005

INCOSE Requirements Management Tools Survey

Requirement Quality Factors September 13, 2005

Clarity

• Can you draw only one interpretation of this use case?
• Does this use case accurately describing the functionality to be delivered?

Completeness

• Does this use case have all the details necessary to implement it? E.g: Missing postconditions
• Identify the area you need more details on, if you have answered ‘No’ to the above question.
• Are all of the requirements related to functionality to be provided by this use case included?
• Are all possible entry/exit criteria for this use case specified?
• Are all the possible error/exception conditions and strategy to handle these conditions identified?
• Are all possible error messages included and do they indicate actual error produced?
• Are all of these requirements related to inputs included?
• Data type
• Range
• Options
• Formats
• Constraints (Eg: Unique)
• Defaults
• Sort order
• Are all of these requirements related to Outputs included?
• List the business terms in the use case that you do not understand.
• Are all units of measure defined? (E.g.: Throughput, Response Time, Availability Time, User Friendly ness etc)

Context

• Are the relationships (extends, includes etc) with other use cases clearly identified?
• Are there any other relationships which are haven’t been identified? (Please specify use case numbers and relationships)

Verifiability

• Can you write a test case for this use case?

Others

• Can this requirement be implemented within known constraints?
• Is there anything in this use case that makes you uneasy?

Necessity / Reason

• Do you understand why customer needs this?

Risk

• Is there a probability that this use case will cause undesired events?

Assumptions

• Are there any assumptions you made or the use case makes?
• Do you have concerns regarding the following issues for this use case:

1. Reliability
2. Performance
3. Security
4. Support
5. Maintenance
6. Deployment

• Does this use case/functionality conflict with any other use case?

Summary

• Associated information
• Complete
• Consistent
• Feasible
• Independent
• Modifiable
• Necessary
• No unnecessary design
• Non-redundant
• Terse
• Testable
• Traceable
• Understandable
• Within scope

More:

http://www.jiludwig.com/Quality.html#Understandable

http://www.csst-technologies.com/reqchklL.htm

Automated Requirement Measurement (ARM) Tool September 13, 2005

The objective of the ARM tool is to provide measures that can be used by project managers to assess the quality of a requirements specification document.

It is an aid to “writing the requirements right”, not “writing the right requirements”.

Automated Requirement Measurement (ARM) Tool

Effects of requirements of poor quality September 13, 2005

• Increase cost and schedule: Effort is spent during design and implementation trying to figure out what the requirements are
• Decrease product quality: Poor requirements cause the wrong product to be delivered or descoping to meet schedule or cost constraints
• Increase maintenance effort: Lack of traceability increases the effort to identify where changes are required, especially as knowledgeable personnel leave
• Create disputes with the customer/client: Ambiguity causes differences in expectations and contractual issues
• Are a major cause of project failure: all of the above

Requirements Traceability Matrix September 13, 2005

• A traceability matrix is created by associating requirements with the work products that satisfy them.
• Tests are associated with the requirements on which they are based and the product tested to meet the requirement
• 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.

Introduction to Requirements Management September 13, 2005

• Requirements management involves establishing and maintaining agreement between customer and developer on both technical and non-technical requirements.
• This agreement forms the basis for estimating, planning, performing, and tracking project activities throughout the project and for maintaining and enhancing developed software
• Key activities include:
• Planning the requirements phase
• Establishing the requirements process
• Controlling requirements changes
• Minimizing the addition of new requirements (scope creep)
• Tracking progress
• Resolving issues with customers and developers
• Holding requirements reviews

Requirements Management Plan

• A requirements management plan is a component of the project management plan.
• Generally, the purpose of RM is to ensure customer and developer have a common understanding of what the requirements for an undertaking are
• Depending on your project standards, a variety of sections might be included in your RM plan. Some examples are:

1. introduction to RM and document overview
2. document scope
3. issues affecting implementation of the plan, such as training on the RM tool
4. applicable documents, such as policies and standards
5. terms and definitions used in the plan
6. methods and tools that will be used for the RM process (or the requirements for selecting a tool if one is not selected)
7. the RM process, including any diagrams of the process
8. authorities and responsiblities of participants
9. strategy for achieving requirement quality, including traceability and change control
10. appendices usually contain a discussion of quality factors, as well as references, any forms to be used in the process, and additional details not included in the main body of the plan, such as report examples

Requirements Management Metrics

• Requirements management can provide vital information.
• For example, by associating costs with requirements and using the data to estimate similar work, improvements in cost estimates are possible.

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 traceability strategy is devised by graphing relationships between work products
• 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
• 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 can it 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

More:

http://www.jiludwig.com/Requirements_Management.html

Requirements Engineering August 26, 2005

Overview

• The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended.
• Broadly speaking, software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation.
• There are a number of inherent difficulties in this process. Stakeholders (including paying customers, users and developers) may be numerous and distributed.
• Their goals may vary and conflict, depending on their perspectives ofthe environment in which they work and the tasks they wish to accomplish.
• Their goals may not be explicit or may be difficult to articulate, and, inevitably, satisfaction of these goals may be constrained by a variety of factors outside their control.
• RE plays an important role in the management of change in software development.
• Nevertheless, the bulk of the effort of RE does occur early in the lifetime of a project, motivated by the evidence that requirements errors, such as misunderstood or omitted requirements, are more expensive to fix later in project lifecycles
• Before a project can be started, some preparation is needed. such as context and groundwork.
• Context: RE is actually performed in a variety of contexts, including market-driven product development and development for a specific customer with the eventual intention of developing a broader market. The type of product will also affect the choice of method: RE for information systems is very different from RE for embedded control systems, which is different again from RE for generic services such as networking and operating systems.
• Groundwork: For groundwork, some assessment of a project’s feasibility and associated risks needs to be undertaken, and RE plays a crucial role in making such an assessment.
• It is often possible to estimate project costs, schedules and technical feasibility from precise specifications of requirements. It is also important that conflicts between high-level goals of an envisioned system surface early, in order to establish a system’s concept of operation and boundaries. Of course, risk should be re-evaluated regularly throughout the development lifetime of a system, since changes in the environment can change the associated development risks.

Eliciting Requirements

• One of the most important goals of elicitation is to find out what problem needs to be solved, and hence identify system boundaries.
• These boundaries define, at a high level, where the final delivered system will fit into the current operational environment.
• Identifying and agreeing a system’s boundaries affects all subsequent elicitation efforts.
• The identification of stakeholders and user classes, of goals and tasks, and of scenarios and use cases all depend on how the boundaries are chosen.
• Identifying stakeholders – individuals or organisations who stand to gain or lose from the success or failure of a system – is also critical. Stakeholders include customers or clients (who pay for the system), developers (who design, construct and maintain the system), and users (who interact with the system to get their work done).
• For interactive systems, users play a central role in the elicitation process, as usability can only be defined in terms of the target user population.
• Users themselves are not homogeneous, and part of the elicitation process is to identify the needs of different user classes, such as novice users, expert users, occasional users, disabled users, and so on
• Goals denote the objectives a system must meet. Eliciting high level goals early in the development process is crucial. However, goal-oriented requirements elicitation is an activity that continues as development proceeds, as high-level goals (such as business goals) are refined into lower-level goals (such as technical goals that are eventually operationalised in a system).
• Eliciting goals focuses the requirements engineer on the problem domain and the needs of the stakeholders, rather than on possible solutions to those problems.
• It is often the case that users find it difficult to articulate their requirements. To this end, a requirements engineer can resort to eliciting information about the tasks users currently perform and those that they might want to perform
• These tasks can often be represented in use cases that can be used to describe the outwardly visible requirements of systems
• More specifically, the requirements engineer may choose a particular path through a use case, a scenario, in order to better understand some aspect of using a system

Elicitation techniques

• The choice of elicitation technique depends on the time and resources available to the requirements engineer, and of course, the kind of information that needs to be elicited.
• Traditional techniques include a broad class of generic data gathering techniques. These include the use of questionnaires and surveys, interviews, and analysis of existing documentation such as organisational charts, process models or standards, and user or other manuals of existing systems.
• Group elicitation techniques aim to foster stakeholder agreement and buy-in, while exploiting team dynamics to elicit a richer understanding of needs. They include brainstorming and focus groups, as well as RAD/JAD workshops (using consensus-building workshops with an unbiased facilitator)
• Prototyping has been used for elicitation where there is a great deal of uncertainty about the requirements, or where early feedback from stakeholders is needed. Prototyping can also be readily combined with other techniques, for instance by using a prototype to provoke discussion in a group elicitation technique, or as the basis for a questionnaire or think-aloud protocol.
• Model-driven techniques provide a specific model of the type of information to be gathered, and use this model to drive the elicitation process. These include goal-based methods, such as KAOS and I* , and scenario-based methods such as CREWS.
• Cognitive techniques include a series of techniques originally developed for knowledge acquisition for knowledge-based systems. Such techniques include protocol analysis (in which an expert thinks aloud while performing a task, to provide the observer with insights into the cognitive processes used to perform the task), laddering (using probes to elicit structure and content of stakeholder knowledge), card sorting (asking stakeholders to sort cards in groups, each of which has name of some domain entity), repertory grids (constructing an attribute matrix for entities, by asking stakeholders for attributes applicable to entities and values for cells in each entity).
• Contextual techniques emerged in the 1990’s as an alternative to both traditional and cognitive techniques. These include the use of ethnographic techniques such as participant observation. They also include ethnomethodogy and conversation analysis, both of which apply fine grained analysis to identify patterns in conversation and interaction

More: http://en.wikipedia.org/wiki/Requirements_analysis

Common Issues with Requirements August 25, 2005

Issues

• Business Analysts’s visualise the system and not business and therefore have too much to do. (Requirements gold-plating) Eg: No reasoning for many features in the spec.
• As they have too much to do, they dont go into detail in the spec
• Business notionally signs off the spec and does’nt visualise it.
• Developers start coding without clear understanding of requirements and uncover grey areas all through.
• Developers dont ask right questions at right time and dont get answers when asked.
• They make either make: Assumptions and proceed which are wrong at time or Ignore the requirement and proceed.
• No involvement of business during the initial testing phases.
• Testing team doesn’t have a clear idea of requirements and can’t write proper test cases and cant uncover bugs in early stages.
• Changes/Issues new requirements during UAT, making changes expensive in terms of time to do.
• No priorites set to developers and hence the ‘must-haves’ are tackled in later phases increasing the risk.
• Business change their mind in between.
• Things break in subsequent phases.

Solutions

Requirememts:

• Every requirement must have a Problem Statement that can be traced back to customer or what the customer is doing currently
• Every Use Case should have Priority, Stability, Necessary features.

Handling Changes:

• Checklist of common requirement categories to ensure the requirements are good
• Dissuade the customer from making changes by rationally explaining how expensive a change can be
• Change-control procedures
• Proto-typing

Facts:

• Change in the early stages of a project, in requirements or architecture, costs 50 to 200 times less than the same change later, in construction or maintenance

Requirements Tools February 11, 2005

Requirements Tools