1. Daniel Siahaan February 2012
SMART Requirements
Daniel Siahaan
February 2012

2. Content Introduction to Requirements Engineering
Perspektif Stakeholder
Requirements Elicitation
Requirements Analysis
Requirements Specification
Requirements Validation

3. SMART Requirements
Non-functional requirements is born to be disputable.
Using the SMART framework a document can be checked and every requirement can be verified as correct in terms of expression (but not content).
Specific Measurable Attainable, Realisable, and Traceable Requirements

4. Specific Requirements
A requirement must say exactly what is required
Clear, i.e. there is no ambiguity
Consistent, i.e. the same terminology has been used throughout the specification to describe the same system element or concept
Simple, i.e. avoid double requirement, e.g. X and Y
Of an appropriate level of detail

5. Guideline for Specific Requirements
Avoid phrases like: obviously, clearly, certainly
Avoid ambiguities like: some, several, many
Avoid list terminators like: etc, and so on, such as
Ensure pronouns are clearly referenced, e.g. “When module A calls B, its message history file is updated”
When numbers are specified identify the units
Ensure all possible elements in a list are described
Use pictures to clarify understanding
Ensure all system or project terms are defined in glossary

6. Guideline for Specific Requirements
Consider placing individual requirements in separate paragraph and individually numbered
Ensure vers such as “transmitted”, “sent, “downloaded”, “processed” are qualified by precise explanations
Only use the word “details”, “information”, “data” in a requirement when you can describe or refer to precisely what they will be
If the requirement is described by a prototype program, ensure that specific program is documented

7. Guideline for Specific Requirements
When a term is defined in a glossary, substitute the definition in the text and then review the requirement
No “To be defined”
“The Mission Planning System shall support several planning environments for generating the mission plan” (bad)
“The system shall support 50 simultaneous users. “ (better)

8. Measurable Requirements
Is it possible, once the system has been constructed, to verify that this requirement has been met.

9. Guideline for Measurable Requirements
What other requirements need to be verified before this requirements Can this requirements be verified as part of the verification for another requirements?
How much data or what test cases are required?
How much processing power is required?
Can the test be conducted on one site?
Can this requirement be tested in isolation?

10. Attainable Requirements
Is it possible physically for the system to exhibit that requirement under the given conditions.
Some requirement may be beyond the bounds of human knowledge or only have a theoretical solutions beyond what is currently achievable.

11. Guideline for Attainable Requirements
Is there a theoretical solution to the problem?
Has it been done before? If not, why not?
Has a feasibility study been done?
Is there an overriding constraint which prohibits this requirement?
Are there physical constraints on the size of the memory, processor, or peripherals?
Are there environmental constraints such as temperature, compressed air?

12. Guideline for Attainable Requirements
“The system shall be 100% reliable and 100% available.” (bad) “The system shall have a minimum response to a query of 1 second irrespective of system load.”(better)

13. Realizable Requirements
Is it possible to achieve this requirement given what is known about the constraints under which the system and the project must be developed
It is often considered in parallel with attainable, but does not however make them synonymous

14. Guideline for Realizable Requirements
Determine who has responsibility for satisfying the requirement
Can they deliver?
Can we afford to manage them?
How badly is it needed?
Are there sufficient resources?
Are we constrained to a particular package which does not support this requirement?
Can we reuse from other projects?

15. Guideline for Realizable Requirements
The requirements are often placed into one of the categories:
Essential
Desirable
Or sometime
Mandatory
Optional

16. Guideline for Realizable Requirements
“The system must have ten operator chairs.” – Essential “The operator chairs should be red.” - Desirable

17. Traceable Requirements
Is the ability to trace (forwards and backwards) a requirement from its conception through its specification, to its subsequent design, implementation, and test.
So that we can know and understand the reason each requirement’s inclusion within the system
So that we can verify that each requirement has been implemented
So that modifications are made easily, consistently, and complete.

18. Parties Who is Interested
SMART user S M A R T
Procurer 
Analysis
Designer
Project Manager
Quality Manager
Test Engineer
Maintainer
End User

19. Personal Exercise
List the non-functional requirements out of your group’s project

20. Project Management
Source: Forsberg, 1997
Successful projects usually use 7 to 15% of project resources (Forsberg, 1997)
On average, projects use 8% of total project resources, during the period of time averaging 20% (Boehm, 2000)