From the course: ISC2 Certified Secure Software Lifecycle Professional (CSSLP) (2023) Cert Prep

Functional requirements

From the course: ISC2 Certified Secure Software Lifecycle Professional (CSSLP) (2023) Cert Prep

Start my 1-month free trial Buy for my team

Functional requirements

“

- [Instructor] In order to effectively secure an application, it helps if you understand why the app exists in the first place. In other words, what business problem does it solve? More to the point, what was it originally designed to do? When you analyze an application with a focus on how the app goes about solving that problem, you'll end up analyzing its functional requirements. Functional requirements are the things that the app absolutely has to do. If you're building an eCommerce application, then you have to provide a way for customers to select the items they want to order, and, ideally, pay for those items. When a project team is planning to build a new application, they pick the functional requirements they can afford to build into the app. So how do project teams determine these functional requirements? Well, I'm glad you asked. First, the business determines that they need an application. If they could automate a process with an app, they could save time and money while improving efficiency. Second, they brainstorm what this app might look like, what it might do. Enter the business analyst. The business analyst takes all these ideas, prioritizes them based on feedback from the requester, and drafts a list of requirements for the development team. Finally, the business analyst takes this set of requirements to the development team where they work together to begin to figure out a roadmap for how they're going to build an application that meets these requirements. This process is cyclical because when the needs of the business change, the cycle begins again. When defining your functional requirements, perspective is everything, and viewing your application from your end user's point of view is the way to go. You do this by generating a handful of common artifacts, business requirements, use cases, and user stories. The flow from business requirements to use cases to user stories can help you find that perspective. Start by defining the business requirements. Generally speaking, these are the things that the end user needs the application to do. Think in terms of end results. Next, define your use cases. These are the specific situations that the user is likely to encounter. When these situations arise, how will the app meet the user's needs? And, finally, use those business requirements and use cases to create user stories, explaining from an end user's point of view. By creating these stories, you're able to visualize a functional, successful application that the user understands. One technique you can use to draw out these requirements is the five Ws and an H. This is the same technique that journalists use when investigating a story. In short, you ask a series of questions, who, what, when, where, why, and, you guessed it, how? Let's take a look at some specific questions that fit this pattern, questions that can help you identify an app's functional requirements. Who are the users? Are they internal employees or external customers? Maybe they're suppliers or partners. By determining who the app users are, your dev team can start planning where those user accounts are going to be stored and how those user accounts are going to access your application. This information will likely trigger a conversation on how you can automate activities like account creation as well as provisioning entitlements to those accounts, maybe even defining user roles within the app. Next, what does the app need to do? This question helps your development team identify the objects that they'll need to create and store, as well as the functions that will have an effect on those objects. Your users, in this case, are the subjects who will act on those objects using the available functions. When will the users need to access the application? Knowing the time of day that your users will be using the app will help your infrastructure team when they try to scale resources up and down in a cost-effective manner. If your app is impacted by seasonal users, then important times during the year should also be considered. Retail applications, for example, often add resources during the holiday season to make sure their shopping carts don't time out on holiday shoppers. The where question is actually two separate questions. Where are the users located, and where is the app infrastructure located? Knowing where your users are located could influence where your app infrastructure needs to reside. If all of your users are in the UK and your servers are in Tempe, Arizona, then your users may experience a little bit of a lag. Why does the business need this app in the first place? This is an important question to keep coming back to so you can make sure that you're not overdesigning or overdelivering. If you focus on simplicity, you're more likely to create something that meets their needs without running out of time or money to create the application. A great way to approach requirements gathering with simplicity in mind is to assume that your users are non-technical. They won't want screens that are text-heavy with more options than they can ever possibly use. They'll want something that's easy to understand, easy to pick up, and easy to use on a regular basis. And, finally, how should the app function? Even though the how question is at the end of this list, it's likely to be at the beginning of the business analyst list. The how question draws out use cases, or those specific actions or steps that need to be performed within the application. From a functional perspective, you can often map use cases back to existing business processes. Use cases should be pretty specific. Following our eCommerce example, they could cover everything from single-click checkouts to notifications about upcoming sales. Understanding an app's functional requirements definitely helps you as the CSSLP bridge your understanding between the development team's design and the user experience. As you'll learn in the next video, it also helps you better understand the non-functional requirements that you should consider.

Contents