Requirements

SMART Technique for writing Requirements

S Specific

Specific requirements say exactly what is needed, be clear (unambiguous), consistent in terminology,
simple and with an adequate detail level.

It is recommended to avoid:

- phrases like “obviously”, clearly”, “certainly”;

- ambiguities like “some”, several”, “many”;

- list terminators like “etc.”, “and so on”, “…such as”;

- “To Be Defined”.

It is recommended to ensure that:

- pronouns are clearly referenced;

- numbers are specified to identify the units;

- all possible elements in a list are described;

- all system or project terms are defined in a glossary;

- verbs that define states (e.g. “transmitted”, “sent”, “downloaded”, “processed”) are explained;

- specific programs are documented if a prototype describes the requirement.

- when a term is defined in a glossary, substitute the definition in the text and then review the requirement.

It is recommended to consider:

- using pictures to clarify understanding;

- placing individual requirements in a

- separate paragraph and individually numbered;

- only use the word “details”, “information”, “data” in a requirement when you can define/refer to what they will be.
M Measurable

Measurable requirements provide information that allows you to verify that they have been met after
building the system. It´s recommended to verify if the software requirements inform:

- The other requirements that would need to be verified before this requirement;

- What needs to be verified as part of the verification by another requirement. If so, which ones;

- The data required to test (How much data or what test cases are required?);

- The process required to test (How much processing power is required?);

- How the test can/should be conducted (one site? in isolation?).

A Attainable

Attainable requirements present what is possible for the system to exhibit this requirement under the
conditions given. It considers the feasibility of the solution, physical/environmental constraints etc.
When writing software requirements, the guideline-recommended is to consider:

- Existing theoretical solution to the problem;

- What has been done before. If not, why not?

- Existing feasibility study;

- Overriding constraints that prohibit this requirement;

- Physical constraints (e.g., the size of the memory, processor or peripherals etc.)

- Environmental constraints (e.g., temperature, compressed air etc.)

R Realizable

Realizable requirements are possible to be achieved, given what is known about the constraints under
the system and the project. The recommended guidelines are:

- Identify who has the responsibility for satisfying the requirement;

- Analyse what is needed to satisfy the requirement;

- Verify if there are sufficient resources, time and budget to deliver;

- Analyse if it is constrained to a particular package which does not support this requirement. Analyse if it will have to be
developed by the project or reused from other projects.

- Place requirements into essential or desirable categories.

T Traceable

Traceable requirements can be tracked (back and forth) from its conception, through its specification, to
its subsequent design, implementation and testing. In specifying a requirement, the provision of the
following supplementary information, where appropriate, should be done:

- originators of requirements (institutions/people);

- underlying assumptions;

- business justifications;

- inter-relationships (e.g., dependency or implication)

- its criticality.

There are many ways to verify the software requirements are SMART; It may need to be part of a major
Quality Assurance process within the organization (and you must know that quality is constrained by the
budget, deadlines and scope of the project, so there are many points to consider).

BABOK Guide V3 by IIBA

Nowadays, the best-known requirements quality acceptance criteria are defined by The Business
Analysis Body of Knowledge® (BABOK® Guide v3 by IIBA®), it defines nine characteristics of the
requirements and design quality: Atomic, Complete, Concise, Consistent, Feasible, Prioritized, Testable,
Unambiguous and Understandable . I see some similarities between the SMART and BABOK criteria, and
would say that you could use both in a complementary way, especially when writing software
requirements under the Information Technology perspective.

Requirement Management
According Business Analysis Body of Knowledge (BABOK)® Guide version 3 defines a knowledge
area called Requirements Life Cycle Management that describes tasks that business analysts should
perform in order to manage and maintain requirements and design information from the whole
requirements life cycle. This cover the knowledge area of Requirement Management.

1. Trace Requirements: analyzes and maintains the relationships between requirements, designs,
solution components, and other work products for impact analysis, coverage, and allocation.

2. Maintain Requirements: ensures that requirements and designs are accurate and current
throughout the life cycle and facilitates reuse where appropriate.

3. Prioritize Requirements: assesses the value, urgency, and risks associated with particular
requirements and designs to ensure that analysis and/or delivery work is done on the most
important ones at any given time.

4. Assess Requirements Changes: evaluates new and changing stakeholder requirements to

determine if they need to be acted on within the scope of a change.

5. Approve Requirements: works with stakeholders involved in the governance process to reach
approval and agreement on requirements and designs.

The Business Analysis information not only begin with a business analyst asking people what they want,
but it starts with the project from the moment it starts. Usually, in a traditional lifecycle environment,
the requirements are created at the beginning, transmitted and validated at the end, and in an Agile
environment, the requirements are represented by functional deliverables, that are created, refined and
reviewed in a circular process. In general, the requirements are incorporated into project documents
such as a project proposal, project scope, business case, and project management plan. So, the business
analyst requirements management process habitually starts following these documents.

IBM’s whitepaper
In IBM’s whitepaper the implementation of the Requirement are shown in 10 steps

Step 1: Structure requirements

Structuring requirements is the first step in taking control and improving its quality. Structured
requirements can improve understanding avoiding duplication and omission. Traceability is a good way
to allow teams to assess the coverage of requirements.

Step 2: Manage and link customer needs, requirements and contracts

It´s needed to capture and manage all levels of user requirements (customer’s needs, contractual
agreements, the specification itself) and maintain intelligent traceability and change impact analysis
between them. The contract and specifications must be managed through a central requirements
repository.

Step 3: Manage constraints.

The requirements should not just describe the functional behavior. Constraints (like non-functional
requirements) can be critical to compliance and regulations and add quality to the system.

Step 4: Visualize requirements

Visual modeling is an important communication tool and facilitates requirements elicitation. Use visual
modeling to provides a simple and powerful way to elicit and communicate the requirements to
stakeholders. It can help to clarify requirements and create a common understanding. (Learn more
about “Modeling Requirements in Business Analysis” here)

Step 5: Test requirements

An efficient way to better manage requirements is to ensure that they are clearly mapped to test cases.
Make sure you can test requirements correctly from the start. The requirements and their tests must
indicate what the system should not do and what happens at the limits.

Step 6: Bridge the chasm between business and development

Sometimes, less is more, and it´s needed to focus on business requirements' value and priority. Instead
of managing all requirements, project and product managers must make decisions about requirements
that bring the most value to the business and improve innovation. This can be achieved by combining
value and priority information from stakeholders and defining the right mix of requirements.

Step 7: Control change to requirements

Requirements are continuously subject to change, so ensure the change management. It is necessary to
implement a reliable and repeatable change control process to transform this challenge into an
opportunity.

Step 8: Capture and track metrics and trends

Follow statistics and trends and ensure that all stakeholders can adequately monitor progress in/around
requirements (for example, through a dashboard). Use trends to learn lessons from previous projects.
Tracking and analyzing trends is a key practice in CMMI levels 4 and 5, leading to the continuous
improvement of corporate guidelines to write better requirements.

Step 9: Provide examples of good requirements

Providing examples of good requirements and documents that can improve the requirements' quality,
consistency, and integrity. These also could be templates, industry standards and rules from a repository
or intranet.

Step 10: Reuse requirements

If a good requirement was written for a previous project and applies to a present situation, reuse it! A
smart approach to reusing requirements is to maintain a link between the two requirements. This allows
analysts to access the original requirement at any time or be aware of any changes made to the original
requirement (problems detected, updates required).

Managing Stakeholders
Effective stakeholder engagement is good for any business. Organizations with a greater
awareness of stakeholder interests and higher stakeholder engagement patterns are more
likely to avoid crisis, simply because they’re in a better position to leverage opportunities and
anticipate risks. Several compelling studies across industries on the impact of good stakeholder
relations demonstrate that, over time, organizations focusing on building stakeholder trust are
more resilient across indicators of value such as financial resilience, sales, cost reduction, time
to market and control of operating costs.
Who are my Stakeholders?

Engagement model

1. Stakeholder analysis/mapping. Analyze stakeholder needs and expectations and think about
how the project or the proposed change might impact stakeholders, as well as how they can
impact the proposed change. Based on this analysis, select an engagement approach that best
suits stakeholders’ needs for effective communication and collaboration.
 2. Plan of engagement. Plan an effective approach to stakeholder engagement. The goal is to
select an approach that will ensure the highest level of engagement throughout the initiative.
Things to consider when selecting an engagement approach may include:

· Style of communication during meetings. Keep the meetings interactive. Initiate and foster
maximum participation.

· Frequency and duration of meetings. Schedule short meetings with an agenda. When meetings are
too long, participants lose their focus.

· Format of meetings. Schedule virtual or in-person meetings as appropriate.

Set expectations. Set and communicate expectations with stakeholders. Make sure the desired
outcomes are clear and well understood by the stakeholders. For example, if BAs request input on
requirements, then they need to make sure that:

· Deadline

· Budget

· Feedback

4. Engage stakeholders. Keep the focus on maintaining and improving the level of engagement. Keep
stakeholders engaged through:

· Maintain the frequency and level of communication. Keep stakeholders apprised of the progress
and possible challenges.

· Active listening. Listen to stakeholders’ concerns and feedback and address them accordingly.

5. Review and adjust. Review and adjust the plan based on stakeholders’ engagement and feedback.
Revisit the approach and adjust for future interactions to maintain the level of stakeholder participation
and involvement.
Interacting and dealing with different types of stakeholders

Communicate if they show

want