Rumor has it, you’re here to learn a little about requirements. You’ve come to the right place, so buckle up; we’re gearing to go full pedal to the metal. Gathering requirements for software development is a necessity in building a product that meets (and exceeds) client expectations. In a nutshell, the process for gathering requirements flows in the following way. First, we consider business requirements; that is, defining basic business needs when it comes to developing a product. From here, we start collecting user requirements, which derive from both functional and nonfunctional areas. While functional requirements tell us what the product must do (the “what”), the nonfunctional requirements will give way to how well the product delivers the “what” (we call this the “technically how”). Documentation of these requirements, as well as appropriate research on business and end-user needs captures the work we’ve done so far. By doing so, we can outline the technical architecture of the software in order to build a product that meets business goals and objectives.
Delivering a software solution relies heavily on this process. It is up to the Project Manager, Requirements Engineer or Business Analyst (here at Briebug, we do it all) to ask the right questions to stakeholders, IT professionals, and any other important figures with interest invested in the project. With that said, one of the most important ideals here is that requirements gathering is all about the user. That’s right, it’s the user’s world and we’re all just living in it. In fact, these questions we ask target the user experience – this includes what we perceive the user to like and dislike, what core functions will keep the user engaged, and even what color scheme is most appealing to the user. Essentially, this is how a project manager or business analyst gets a hold of true business requirements, user needs, and technical aspects of a project.
Functional vs. Nonfunctional Requirements
But that’s not why we’re here, are we? Let’s talk about functional and nonfunctional requirements. Functional requirements indicate the absolute necessities of the software; these requirements reflect the user-stated functionality, or features, he or she needs in order for the product to have optimal value. Functional requirements outline features that not only support the purpose of the product, but also provide the end-user with the experience business owners have envisioned. These functional requirements help to understand the reason for the business needs as told by project stakeholders and the end-user, as well as to define the scope of the project.
Conversely, nonfunctional requirements indicate the quality attributes and rules of the end product. The nonfunctional requirements answer questions of “how will our solution fulfill the functional requirements necessary for a quality product?” These requirements will outline how the characteristics of the product support its functionality and design, along with how well these attributes do that. While functional requirements are generally simpler to define, nonfunctional requirements are needed for reasons such as verifying functionality, quality assurance, and performance. Both functional and nonfunctional requirements are gathered from the business and its stakeholders, while architects are often involved in gathering nonfunctional requirements in order to determine the ways in which they can achieve optimal implementation.
Examples of Functional vs. NonFunctional Requirements in Software
Let’s consider an MVP (Minimal Viable Product), where we develop minimal features that address enough proof of concept to get buy-in from your target audience. Built mostly by functional requirements, an MVP will also need nonfunctional requirements to expand the product and its effectiveness down the line (i.e., security, reliability, performance, and maintainability). Here, we understand that functional requirements help to develop a primary system that includes the user’s wants and needs. Even though nonfunctional requirements are not usually part of the critical path for project success, they help to define items like usability and scalability.
With that said, if you’re anything like me, I need a specific example to understand functional vs. nonfunctional requirements (show me the receipts, right?). A simple example of a functional requirement would look like something along the lines of “As a user, I want to enter my email address and password, so that I can log into the application and interact with functionality.” Here, we see the most standard form of writing functional requirements in Agile, which is the user story. Don’t sweat it, we’ll get more into this later on. On the other hand, a nonfunctional requirement would be written as such: “As a user, I must agree to the privacy policy before entering personal information.” This simple statement supports the functional requirement of entering personal information to log into the application, but is also deceivingly technical as it requires an understanding of legal and regulatory policies.
How Does the User Story & Use Case Differ
Remember when I mentioned we would get to know what user stories are? Well, you made it this far, so keep on reading. In agile, the user story is widely used to define requirements for software development.
The main difference between user stories and use cases is that stories are widely used in agile methodology, while use cases are utilized in waterfall methodology. Now, this does not mean you can’t employ use cases in agile; and while they correspond to the actor’s (user’s) goals, they just contain a much higher level of detail that agile methodology does not require. In waterfall projects, use cases make sense because they are often developed by way of strict documentation.
User stories, on the other hand, will focus on the working product over stricter documentation. This works well in agile projects because agile is iterative; when something does not work, it can be returned to and altered to be more suited for the user. As part of Agile best practices, user stories are created as such: “As a user, I want (goal), so that (outcome).” User stories are much lighter in weight, but do provide more detail for the folks developing the software, as well as including acceptance criteria. Acceptance criteria generally include business rules and nonfunctional requirements that encapsulate the definition of the functional requirement.
Conclusion
So now you know a little more about requirements, functional vs. nonfunctional, who writes them, where the pertinent information comes from, and what they include. We’ve reached the finish line, but in case you skimmed, here’s a recap.
Generally speaking, requirements gathering is needed at the commencement of a project because the information attained at this time helps to build the most suitable product for the stakeholders’ needs. This process is reliant on asking stakeholders the right questions (i.e., those that target the end-user). This is generally done by a business analyst or project manager, who obtains requirements from stakeholders, or those who can speak to the end-user experience. Requirements are written in the form of user stories or use cases, depending on the methodology taken by the project.
We also now know the key difference between functional and nonfunctional requirements is that functional requirements define the “what,” while nonfunctional requirements define the “how.” Functional requirements are elementary to any project, and even though nonfunctional requirements are not tied to the critical path of project success, they are a tool in verifying functionality, conducting quality assurance, overall product performance with scalability and are very helpful to architects who ensure the final product is as perfect to our stakeholders as possible.
Well, that’s all I have today for requirements. If you’re now a die-hard fan of all things requirements writing (because I’m sure you are now), talk to your friendly neighborhood PM or BA. We love a good discussion.