developing smart software requirements

Developing SMART Requirements

January 06, 2010

• Purpose

• SMART Concept – Background

• SMART Definition

• Applying SMART Principles

Developing SMART RequirementsAgenda

Developing SMART RequirementsPurpose

Purpose

• The presentation discusses in context these ideas:

• A requirement, at its most basic level, is a desired and predictable outcome; and

• Consistent methods for creating testable requirements benefit the project bottom-line.

Developing SMART RequirementsSMART Background

SMART Concept – Background

• Benefits of using SMART requirements:

• Budget and schedule advantages are gained;

• Consensus is more quickly reached; and,

• Rework is decreased.

Developing SMART RequirementsSMART Definition

SMART Requirements – alternates in ( ):

• Specific;

• Measurable

• Attainable (Achievable, Actionable, Appropriate)

• Realistic (Relevant)

• Time-Bound (Timely)


SMART Definition – Specific:

• Specific requirements are precise and:

• Are not open to interpretation; and

• Avoid absolutes (ex. – “all”, “never”, “always”).


SMART Definition – Specific (Poor):

• The document will contain all customer information:

• Which document?

• What customer information?

• What format(s)?


SMART Definition – Specific (Improved):

• This requirement has improved precision:

• The Declaration document shall contain this customer information in a text block in the top right corner of the first page:

• Customer Name

• Phone

• Email


SMART Definition – Measurable:

• Measurable requirements can be verified as complete and:

• Avoid undefined time periods / quantities; and,

• Avoid non-fact based measurements such as “best” or “optimal”.


SMART Definition – Measurable (Poor):

• The application shall function quickly for end users:

• How quickly (seconds, minutes, hours)?

• Which application features are included?

• Which users are affected – guests, administrators, everyone?


SMART Definition – Measurable (Improved):

• This requirement has improved measurability:

• The application shall have response times of 4.00 seconds or less for all features, and for all user roles, during business hours of 9 AM – 5 PM ET, Mondays – Fridays.


SMART Definition – Attainable:

• Attainable requirements are able to be achieved given the existing environment and are:

• Appropriate for project / limitations; and,

• Realistic to achieve within project parameters.


SMART Definition – Attainable (Poor):

• The monthly cycle will be run on the last Friday of the month, between 7 PM and 8 PM ET:

• Has this been verified to be possible?

• What if the cycle runs longer than 1 hour?


SMART Definition – Attainable (Improved):

• This requirement has improved attainability:

• The monthly cycle will be run on the last Saturday of the month, starting at 7 AM and completing by 7 PM ET.


SMART Definition – Realistic:

• Specific requirements are relevant and:

• Are appropriate in context with other requirements; and,

• Consider other related project constraints.


SMART Definition – Realistic (Poor):

• The new website will generate over 1,000,000 hits within its first12 hours of implementation:

• Is this likely / necessary to occur?

• Is there a better way to measure this outcome?


SMART Definition – Realistic (Improved):

• This requirement has improved relevance:

• The new website shall be ranked within the first results page on three (3) major search engines (Google, Bing and Yahoo) within its first 12 hours of implementation.


SMART Definition – Time-Bound:

• Time-Bound requirements are timely and:

• Clarify how quickly a requirement needs to be finished, executed or implemented.

• Avoid vague time references such as “fast”, “quick” or “soon”.


SMART Definition – Time-Bound (Poor):

• System availability will be achieved soon after the cycle is completed:

• How soon (seconds, minutes, hours)?

• What if the cycle is late?


SMART Definition – Time-Bound (Improved):

• This requirement has improved timeliness:

• System availability shall be achieved after cycle completion and by no later than 6 AM ET on Mondays – Fridays.

Developing SMART RequirementsQuestions

Questions

developing smart software requirements

Documents