Software Requirements

While the role of eliciting requirements may traditionally fall upon a business analyst. This job title does not always exist, especially in organizations that use Agile. As such, an understanding of what is meant by requirements is important for analysts, customers, developers, and any management types involved (product owners, project managers, etc.) Based upon a lot of reading and interactions with people, I've grown to like the following definitions. When gathering requirements, every level should be addressed (even if it's N/A).

  1. Business Need - what is the customer trying to get done and why. If you are servicing customers internal to your own organization, the answer to this question may determine whether the software is developed internally or purchased off the shelf.

  2. User Stories - how are the software going to use the software and what kind of users are they going to be.

The following will be derivative of the first two.

  1. Features - specific behavior or functionality detailed individually; this will be visible to users
  2. Functional/Non-functional requirements - at this point, I consider constraints (compliance and legal) or other things in the environment that will influence the actual design of software if it comes to that. Interfaces with other systems may also come into play. These are levels that I usually consider just to get a technical conversation started. Longterm sustainment of software, help-desk support, and predicting future business requirements are also a key component for making a product successful.

Now, there's no lack of Software Requirement Specification templates, and I would recommend browsing a few and determining what might be useful for you. If you'd like to read further on the topic along with tips on how to improve the requirements gathering process, I'd recommend Software Requirements (2013) by Karl Wiegers & Joy Beatty.

You may also like