In many definitions of Business Analysis, you'll often see statements like, “BAs should be concerned about the what and not the how”, "BAs are not software designers" or “Specifications should be devoid of implementation details”. In practical terms, I have found that it is difficult and almost idealistic, to document requirements without having a vision of what the final system would look like. Most times, that vision, which is the product of a particular design, has a strong impact on the specifications we write.
On a recent project, the stakeholders wanted a means of uniquely identifying employees in the system. They emphasized the need for a card reader which would automatically capture the details of employees. On further analysis however, it was discovered that a Username/PIN system would be much faster, cheaper to implement and deliver the same functionality. Consequently, we had to include in the specifications, a requirement to "generate user PINs". Now, this requirement would never have come up if we hadn’t thought of “how” the employee identification requirement would be achieved. Requirements often contain design elements which are expressed through analysis models like prototypes.
Without implying that the statement “Business Analysts should be concerned about the what and not the how” is wrong, I strongly believe it would clear up a lot of confusion to emphasize that the “what” can determine the “how” as much as the “how” can determine the “what”.
One could also argue that it would be more beneficial to project teams if BAs were to practise both analysis and design. Agile teams in particular, would argue that BAs are required to be generalizing specialists, meaning that they should be good at more than just analysis.
Though software design is not the primary responsibility of the BA, the BA, just like any other member of the team, can support the design process. While writing a requirements specification document without thinking of the future state (which is determined by the design) is difficult to achieve, design constraints should at least, be kept to a minimum in the software specifications document.
The specification of requirements involves elaborating, refining and organizing requirements into documents that the developer and stakeholders can read. Because users and developers have a stake in the requirements specification document, they should have some input into its content as well as the process of creating it.
So, as an analyst, you can start by:
- Creating a user requirements document, which is a raw outline of what users have requested for and why they need it. This can also be referred to as a Requirements Definition Document. When meeting with stakeholders to discuss their requirements, you would want to document their requirements to reach an agreement on what the system should do. These requirements are presented at a high-level of detail and form the basis of deriving the software specifications. You could also employ use cases to illustrate how the user intends to use the system; a context diagram for showing how the system would interface with other systems in the organization and the business rules that would affect the operation of the system
- Incorporating requirements into a software specifications document directly. The software requirements specification document is a more precise definition of prioritized requirements that is used as a starting point for designing, developing and testing the software solution. It goes beyond the requirements elicited directly from users to include non-functional requirements. It may also be referred to as a Functional Specifications Document. With this document, the analyst takes the user requirement statements and transforms them into precise textual statements which may form the basis of a contractual obligation, particularly for situations where the software development project is outsourced to an external company.
It’s important to know that while requirements are typically classified as Business, Stakeholder, Solution (functional and non-functional requirements) and Transition requirements, there are other categories of requirements (outside of the Software Specifications Document) that need to be considered - For example, process changes, additional resources and other project requirements which may or may not be directly managed by the analyst, depending on the structure of the organization.