By Julie Ramsey, Scrum Master

Technique 10.30 – Non-Functional Requirements Analysis
Purpose – Examine what a solution needs to determine how well the functional requirements must perform.  Specifically, how to measure the operation of a system as compared to its behavior. 
Description – Non-functional requirements are sometimes called quality attributes or quality of service requirements.  They support and identify constraints on the functional requirements or the specific behaviors of a system.  Non-functional requirements are often expressed in a format such as “errors must not exceed X per use of the process, transactions must be at least X% processed after S seconds, or the system must be available X% of the time.”
Categories of Non-Functional Requirements – There are 15 categories defined in this technique.  This is just a sampling of the full list. 

  • Availability – Often expressed as a percent of time, it is the degree to which a solution is accessible for use
  • Performance Efficiency – How well a system performs its functions using minimum resources.  It may be defined in the context of time such as high-peak versus off-peak usage.
  • Security – Part of the solution that protects from accidental access or malicious modification.
  • Service Level Agreements – Constraints formally agreed upon by the provider of the solution and its users.
  • Maintainability – How easily the solution may be modified for improvement, correction of issues or adaptation to change.
  • Certification – Requirements needed for the solution to meet standards.
  • Compliance – Constraints in the areas of regulation, finance or legal terms.

Measurement of Non-Functional Requirements – Often expressed in vague terms, it is most useful to describe non-functional requirements in a measurable format so they can be verified.  For example, saying ‘the system must allow for quick login’ is vague.  Instead ‘ninety percent of logins must take less than three seconds’ is verifiable.  Some categories of non-functional requirements are measured based on external constraints like those established by organizations that govern standards or by a company’s architectural group.
Context of Non-Functional Requirements – Impact of context varies based on the category.  Finding the right balance of non-functional requirements based on context is key to delivering value.  Non-functional requirements may be impacted by changes to the context or changes to one category may impact a different category.  For example, reduced resources in one region may impact maintainability there resulting in a lower accepted performance.
Usage Considerations – Strengths

  • Constraints on the functional requirements are clearly defined.
  • Non-Functional Requirements clearly describe how the functional requirements must perform.

Usage Considerations – Limitations

  • There may be conflict between requirements such that compromises may be necessary.
  • Users may have differing expectations making it difficult to agree on quality attributes.

Technique 7.20 – Story Mapping
Purpose – Create an understanding of product functionality and flow, plus assist with ordering planned delivery of product.
Description – Provides a visual picture of how activities will be sequenced horizontally while displaying details and order vertically.  Using story mapping allows for high level ideas to be decomposed so the solution may be visualized.  The delivery team may refer to the story map while planning and it may remain displayed in the team space for future reference.  Story maps may help to find dependencies, risks and define flow of work to deliver a solution.
Themes or Activities – The first horizontal row shows all the activities a customer may perform.  It includes all personas and activities specific to those different perspectives.
Stories or Features – The second horizontal row and below include stories specific to the above activities.  The stories may apply to one or more personas.  Stories may also be grouped into features.
Ranked Priority Order – Stories are ordered so those at the top will take priority and those at the bottom have the lowest priority.  Order is considered based upon stories that deliver the most value for the most customers.  Dependencies are also considered when stories are prioritized.
Facilitation – There is not a need for a dedicated facilitator when story mapping.  It tends to be done as a group activity.  The team may prioritize stories, discover missing stories and split stories into smaller stories.  The Product Owner can help the team during discussions of order.  It is useful to prepare the activities and stories in advance so the team can focus on the prioritization.
Usage Considerations – Strengths

  • Story Mapping helps the team focus on the big picture and what value they are trying to deliver.
  • It may aid in visualizing the flow of data in the system.

Usage Considerations – Limitations

  • Story Mapping may be cumbersome if the solution is large.
  • It is less useful for non-process-oriented contexts.