To get an idea where requirement analysis and other knowledge areas fit in the overall flow of business analysis activities, it is good to have a process flow diagram. The following picture depicts the relationship between knowledge areas through a process view of the activities performed in various knowledge areas.
- Requirement Elicitation is part of Chapter 4 of BABoK and the tasks in it represented as 4.1, 4.2 and 4.3 in below picture.
- This is followed by Requirement Analysis which is represented as 7.1, 7.2 and 7.3.
- Requirement Lifecycle management is covered through 5.1, 5.2, 5.3, 5.4 and 5.5 below.
- The initial step of Strategic Analysis is depicted as 6.1 and 6.2 below.
Requirements Analysis
1.Specify and Model Requirements: describes a set of requirements or designs in detail using analytical techniques.
2.Verify Requirements ensures that a set of requirements or designs has been developed in enough detail to be usable by a particular stakeholder, is internally consistent, and is of high quality. (Doing things right)
3.Validate Requirements ensures that a set of requirements or designs delivers business value and supports the organization’s goals and objectives. (Doing the right things)
Relationships between types of requirements
Vision Statement
Illustration of Vision Statement
Sample Business Objectives
Model and Model Categories
•A descriptive and visual way to convey information to a specific audience in order to support analysis, communication, and understanding (E.g. Tables, Diagrams)
•Used to confirm knowledge, identify information gaps that the business analyst may have, and identify duplicate information.
Model categories
1.People & Roles models represent organizations, groups of people, roles, and their relationships within an enterprise and to a solution.
2.Rationale: Why a change is required? E.g. Root Cause Analysis, Decision Modelling
3.Activity Flow models represent a sequence of actions or events E.g. Usecases, Process model
4.Capability models focus on features or functions of an enterprise or a Solution E.g. Prototyping
5.Data & Information models represent the characteristics and the exchange of information within an enterprise or a solution E.g. Data Flow Diagram, State Modelling
Modeling Techniques
Decision Models
Swimlane Diagram
State Modeling
A state model describes:
• a set of possible states for an entity,
• the sequence of states that the entity can be in,
• how an entity changes from one state to another,
• the events and conditions that cause the entity to change states, and
• the actions that can or must be performed by the entity in each state as it
moves through its life cycle.
Elements of a State Model
• State
• Transition (with event, role, duration and other attributes as required)
• Link
State Modeling – ATM (Illustration)
State Model Illustration Chemical Tracking System – States of a Request
This STD shows that an individual request can take on one of the following seven possible states:
In Preparation The Requester is creating a new request, having initiated that function from
some other part of the system.
Postponed The Requester saved a partial request for future completion without either
submitting the request to the system or canceling the request operation.
Accepted The Requester submitted a completed chemical request and the system accepted
it for processing.
Placed The request must be satisfied by an outside vendor and a buyer has placed an order
with the vendor.
Fulfilled The request has been satisfied, either by the delivery of a chemical container from
the chemical stockroom to the Requester or by receipt of a chemical from a vendor.
Back-ordered The vendor didn’t have the chemical available and notified the buyer that it
was back-ordered for future delivery.
Canceled The Requester canceled an accepted request before it was fulfilled, or the buyer
canceled a vendor order before it was fulfilled or while it was back-ordered.
Feature Tree
Context Diagram (Illustration)
Legend to the Context Diagram
Use Cases
Use cases describe the interactions between the primary actor, the solution, and any secondary actors needed to achieve the primary actor’s goal.
Use cases are usually triggered by the primary actor, or an external event or a timer.
A use case is started by an actor, referred to as the primary actor for that use case.
Other actors who participate in the use case in a supporting role are called secondary actors.
Sample Use Cases
Use Case Diagram
Click here for a quick introduction to Use Case Diagram
Sample Use Case Diagram
Sample Use Case Template & Illustration
User Stories
A user story represents a small, concise statement of functionality or quality needed to deliver value to a specific stakeholder. User stories can be hierarchical.
It is a statement of value with following:
• Who: a user role or persona.
• What: a necessary action, behaviour, feature, or quality.
• Why: the benefit or value received by the user when the story is implemented.
User Story Template: “As a [persona], I [want to], [so that].”
E.g. As a manager, I want to be able to understand my colleagues’ progress, so I can better report our success and failures.
Illustration of traceability from Application to User Story
Sample Non-Functional Requirements:
Look and Feel Examples.
The product shall be attractive to a teenage audience. Fit Criterion: A sampling of representative teenagers shall, without prompting or enticement, start using the product within four minutes of their first encounter with it.
The product shall comply with corporate branding standards. Fit Criterion: The office of branding shall certify that the product complies with the current standards.
Non Functional requirements are the ones which are relatively difficult to identify and document. Here are some examples to illustrate various dimensions of Non-Functional Requirements from https://www.cs.uic.edu/~i440/VolereMaterials/templateArchive16/c%20Volere%20template16.pdf.
Ease of Use Examples:
To guide the product’s designers toward building a product that meets the expectations of its eventual users.
The product shall be easy for 11-year-old children to use. Fit criterion: Eighty percent of a test panel of 11-year-old children shall be able to successfully complete [list of tasks] within [specified time].
The product shall help the user to avoid making mistakes. Fit criterion: One month’s use of the product shall result in a total error rate of less than 1 percent.
The product shall make the users want to use it. Fit criterion: An anonymous survey shall show that 75 percent of the intended users are regularly using the product after a three-week familiarization period.
Performance – Speed & Latency Examples
•Any interface between a user and the automated system shall have a maximum response time of 2 seconds. Fit criterion: The product shall respond in less than 1 second for 90 percent of the interrogations. No response shall take longer than 2.5 seconds.
•The response shall be fast enough to avoid interrupting the user’s flow of thought.
•The product shall poll the sensor every 10 seconds.
•The product shall download the new status parameters within 5 minutes of a change.
Precision & Accuracy Examples
All monetary amounts shall be accurate to two decimal places.
Accuracy of road temperature readings shall be within ±2°C.
Reliability & Availability Examples
The product shall be available for use 24 hours per day, 365 days per year.
The escalator shall run from 6 A.M. until 10 P.M. or until the last flight arrives.
The product shall achieve 99 percent uptime
Performance – Robustness & Fault-tolerance Examples
•The product shall continue to operate in local mode whenever it loses its link to the central server.
•The product shall provide 10 minutes of emergency operation should it become disconnected from the electricity source.
Performance – Capacity Examples
The product shall cater for 300 simultaneous users within the period from 9:00 A.M. to 11:00 A.M. Maximum loading at other periods will be 150 simultaneous users.
During a launch period, the product shall cater for a maximum of 20 people to be in the inner chamber.
Scalability Examples
The product shall be capable of processing the existing 100,000 customers. This number is expected to grow to 500,000 customers within three years.
The product shall be able to process 50,000 transactions per hour within two years of its launch.
Characteristics of ideal requirement statements
Complete but concise: Each requirement must contain all the information necessary for the reader to understand it. In the case of functional requirements, this means providing the information the developer needs to be able to implement it correctly. They should be Atomic – self-contained and capable of being understood independently of other requirements or designs.
Correct: Each requirement must accurately describe a capability that will meet some stakeholder’s need and must clearly describe the functionality to be built. You’ll have to go to the source of the requirement to check its correctness.
Feasible: It must be possible to implement each requirement within the known capabilities and limitations of the system and its operating environment, as well as within project constraints of time, budget, and staff. (How to ensure Feasibility?)
Necessary: Each requirement should describe a capability that provides stakeholders with the anticipated business value, differentiates the product in the marketplace, or is required for conformance to an external standard, policy, or regulation.
Prioritized: Prioritize business requirements according to which are most important to achieving the desired value.
Unambiguous: Should be understandable and in the same way by different people
Verifiable: Can a tester devise tests or other verification approaches to determine whether each requirement is properly implemented?
Characteristics of ideal requirement collections
Complete: No requirement or necessary information should be absent. Difficult to identify missing requirements as they are not there. (How to ensure Completeness?)
Consistent: Consistent requirements don’t conflict with other requirements of the same type or with higher-level business, user, or system requirements. If you don’t resolve contradictions between requirements before diving into construction, the developers will have to deal with them. (How to ensure Consistency?)
Modifiable: You can always rewrite a requirement, but you should maintain a history of changes made to each requirement, especially after they are baselined. You also need to know about connections and dependencies between requirements so you can find all the ones that must be changed together.
Traceable: A traceable requirement can be linked both backward to its origin and forward to derived requirements, design elements, code that implements it, and tests that verify its implementation.
Verification of Requirements: Checking if we are Doing things right
Ensures that requirements specifications and models meet quality standards and are usable for the purpose they serve.
Some aspects checked during verification
- Correctness – requirements have been defined correctly.
- Readiness for validation – to determine that the requirements and designs are ready for validation
- Comprehensive – provides the information needed for further work
- Easy to Understand – by its intended audience.
- Represent Reality – requirements must represent reality
- Fitness for use – meet the needs of stakeholders who will use them for a particular purpose
- Standards/Notations Usage
Validation of Requirements: Checking if we are Doing the right things
•Ensure that all requirements align to the business requirements and support the delivery of needed value
•Understanding of desired future state helps in validation
•Validation process exposes possible conflicting needs & expectations of various stakeholders
•Requirements Walkthrough Meeting –all necessary stakeholders
•Sign-off on the Requirements from all stakeholders
Identify Assumptions: So that stakeholders’ assumptions on returns/benefits are captured
References
- https://www.atlassian.com/agile/project-management/user-stories
- Software Requirements, Karl E. Wiegers, Microsoft Press
- Business Analysis Body of Knowledge (BABOK)
- https://www.cs.uic.edu/~i440/VolereMaterials/templateArchive16/c%20Volere%20template16.pdf
Dr. Selvaraj Vadivelu 