Concepts

A fundamental skill required to pass the “PMI Professional in Business Analysis (PMI-PBA)” exam is the ability to write good, quality requirements that are both measurable and actionable. These are typically written using various techniques such as use cases, user stories, along with data and interface details. The main objective behind writing these types of requirements is to communicate effectively with the development and implementation teams.

Writing requirements specifications may seem simple but it’s actually more complex than meets the eye. It entails capturing clearly and in great detail the needs of users, expectations of stakeholders, system characteristics, and more, in a manner that leaves little or no room for interpretation or errors.

II. Approach to Writing Requirements Specifications

1. Use Cases:

Use cases are a brilliant way to depict how a user interacts with a system to achieve a goal. They illustrate the sequence of actions that lead to a desirable outcome. This narrative style of requirement specifications is most useful because it naturally describes the function from the user’s perspective.

For example, let’s consider the use case of a user logging into an online banking system. This would follow the following steps:

  • The system prompts the user to input username and password.
  • The user inputs the correct username and password.
  • The system validates the credentials and logs in the user.
  • End of use case.

In addition, each use case should include possible errors or exceptions that could occur during interaction. In our example, the error would be providing incorrect username or password.

2. User Stories:

User stories, on the other hand, are a more informal and condensed method for defining requirements. In the simplest terms, a user story describes the type of user, what they want, and why. It does not detail how the functionality will be implemented.

Taking again the banking system example, an example of a user story would be: “As a Bank Customer, I want to log into my account, so that I can view my account balance.”

User stories are beneficial as they help to put into perspective the value that each requirement sheds on the final product and its end user.

3. Data and Interface Details:

The final aspect is including data and interface details that are essential portions of the requirement specification. This aids in defining the system’s behaviors, especially in the context of how the system interacts with its users. The details also ensure that data integrity and compliance rules are met and that the interface is user-friendly.

III. Writing Measurable and Actionable Requirements

An efficient business analyst should work towards writing requirements that are measurable and actionable. This helps to know when a requirement has been adequately fulfilled. The “SMART” approach is a beneficial guide here. “SMART” stands for Specific, Measurable, Achievable, Relevant, and Time-boxed.

Remember, a good requirement specification would allow any competent developer to design and implement the system accurately, without the need for excessive clarification or interpretation. Thus, understanding and practicing these techniques is vital to enhance your skill set, pass the PMI-PBA exam, and truly excel in your profession.

To conclude, it is essential to note that regardless of the technique or method chosen for writing requirements, the ultimate objective is clear and effective communication.

Answer the Questions in Comment Section

True or False: The process of writing requirements specifications is purely focused on noting down the wants and needs of the user without considering its measurability and actionability.

  • True
  • False

Answer: False

Explanation: The process of writing requirements specifications not only involves understanding the user needs but also ensuring that these are measurable and actionable to be suitable for development.

Which of the following methods is considered appropriate for communicating requirements that are measurable and actionable?

  • a) Use cases
  • b) Prototypes
  • c) User stories
  • d) All of the above

Answer: d) All of the above

Explanation: Use cases, prototypes and user stories are all effective methods to communicate requirements in a manner that is measurable and actionable.

True or False: Non-functional requirements need not be measurable.

  • True
  • False

Answer: False

Explanation: Non-functional requirements, which describe how a system should behave, also need to be measurable to ensure that they are suitable for development.

Which of the following is NOT a part of requirement specification for communication requirements?

  • a) Use cases
  • b) Software interface
  • c) User manual
  • d) Data

Answer: c) User manual

Explanation: User manual is not a part of requirement specification but it is a part of user support documentation.

True or False: Requirements specifications should be actionable in nature, regardless of their complexity.

  • True
  • False

Answer: True

Explanation: Regardless of their complexity, requirements specifications should always be actionable. This means that developers should be able to use them to create the necessary software features.

What does the term ‘actionable’ in relation to requirements specification mean?

  • a) They involve actions
  • b) They can be acted upon by developers
  • c) They require immediate action
  • d) They involve a significant amount of effort

Answer: b) They can be acted upon by developers

Explanation: An actionable requirement means that the requirement is articulated clearly enough that developers can begin working on it.

What is the primary purpose of use cases in requirement specifications?

  • a) To analyze cost
  • b) To map user interaction with the system
  • c) To estimate development time
  • d) To formulate marketing strategies

Answer: b) To map user interaction with the system

Explanation: Use cases primarily map out the interactions between a user and a system and are vital for understanding user requirements.

True or False: User stories are a way to represent the requirements of the customer in their own language.

  • True
  • False

Answer: True

Explanation: User stories allow requirements to be expressed from the perspective of the customer, often written in their own language, to facilitate better understanding.

Which of the following is NOT true regarding requirement specification?

  • a) Requirements must always be measurable.
  • b) Requirements should be precise and unambiguous.
  • c) Requirements need not always be testable.
  • d) Requirements should be actionable.

Answer: c) Requirements need not always be testable.

Explanation: All requirements should ideally be testable to ensure proper functionality in the end product.

Are use cases and user stories synonymous terms when it comes to requirement specification?

  • a) Yes
  • b) No

Answer: b) No

Explanation: While both use cases and user stories are used for requirement specification, they serve different purposes. Use cases map user-system interaction whereas user stories represent customer requirements in their own language.

0 0 votes
Article Rating
Subscribe
Notify of
guest
22 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Giray Günday
6 months ago

Great article on writing requirements specifications! Use cases are so essential for visualizing user interactions.

Kay-Uwe Klug
7 months ago

Thanks for this informative post! I’ll definitely incorporate more user stories into my future projects.

Volkan Aybar
7 months ago

I have a question. How detailed should data requirements be when creating specifications?

Gafiya Kozhuhar
7 months ago

User stories are powerful but sometimes I struggle with acceptance criteria. Any tips?

Luisa Da Silva
7 months ago

This post was really helpful! Appreciated!

Isabéu de Souza
7 months ago

Interface details can often be overlooked. I find including wireframes and mockups useful. Do others agree?

Gafiya Kozhuhar
7 months ago

I appreciate this article, it bridges a lot of gaps!

Josefine Christensen
7 months ago

I think focusing only on process requirements isn’t enough. We need a balance of process, data, and interface details.

22
0
Would love your thoughts, please comment.x
()
x