Daniel Siahaan February 2012 SMART Requirements Daniel Siahaan February 2012

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

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

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

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

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

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)

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

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?

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.

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?

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)

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

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?

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

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

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.

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

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

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)