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).
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.
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.
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.
What do we do about CDNs in DoD/Enterprise environments?Read More >
Technology cannot solve a management problem.Read More >
Some time ago we contracted a vendor to develop a small application for us. After multiple setbacks throughout the project, I received a phone call.Read More >