In the last section, we talked about some of the different requirements and the fact of needing to get good ones from our clients. However, in this section, we will be dealing more with some techniques that we can use to promoting even a better environment for positive communication. This section also deals with other tools such as policy decomposition, traceability requirements, use/misuse cases and then last is the classification of data based on structured or unstructured. So, from last time again, we talked about gathering requirements but now we need to talk about how to elicit data gathering from your stakeholders and the clients so as to have the best possible sources of information and so ultimately, you have the best set of requirements with the most specific sets of expectations, so it is possible to meet or exceed the client’s expectations.
Getting a good, strong foundational set of requirements is involved with trying to meet the client’s expectations. Some of the techniques are brainstorming, getting stakeholders together for an affinity mapping, when categorized they are better to associate when grouped together. Other techniques include facilitator workshops, surveys, questionnaires, and interviews. These all represent what it takes to gather information which will pretty much determine how well your software can be produced. Brainstorming involves getting the stakeholders together and working out what exactly they need from the application. Affinity mapping helps with categorizing and prioritizing maybe based on technical, security, or operating requirements. Once they’ve been grouped or categorized based on concept, then it’s easier to associate what task to which area of the discussion. Facilitated workshops, much like it sounds where there is a facilitator that helps guide through the process to ask the probing questions and find out the information in an organised fashion. These are all techniques for when the stakeholder is able to meet in person. However, not every time will you get every single person involved to meet. Instead there are other tools to use.
Even if not every stakeholder is able to attend the meetings where the information gathering is occurring, then surveys and questionnaires can still shed some light as to interests and specific aspects to help those actually using the application be more adept at its usage. Typically on a project, there are meetings with the high end or upper management who have a vision of what they want out of the application but are not the actual end user, so it’s just as important to get the end user’s opinions as well. This is another way to get information from groups of people. When you want a little more of the one on one meeting, you may want to use the interview tool. The important thing is to get everyone’s perspective and get the appropriate information from all stakeholders involved to get a more thorough understanding of what the expectation of your team and your organization in producing a product for the stakeholders involved. Some other tools that we can talk about a little more specifically like policy decomposition, tracing requirements or requirements traceability, protection needs elicitation, use and misuse cases.
Policy decomposition is taking some of those high level objectives, derived from the high level upper management and then breaking them down into management components. This is so that the project team is actually able to complete the work in a timely fashion. The starting point is very broad and then the objectives that are actually more obtainable each have a more narrow focus. For example, there may be a need to store medical information and we have to make sure we stay HIPPA compliant. So, how vague and broad that statement is, that is our starting point. So, one of the manageable goals is to have confidentiality protection, secure transmission and privacy. So, all of these are come down to security protocols and requirements where for example, we might have to have identity management, where even that more narrow goal is broken down in an even more narrow focus. This can be further broken down into validating the software, when having input to have exception handling, and such. So, with reference to the breaking down or chunking some of the more broad objectives from upper management, policy decomposition creates smaller goals that are more manageable. These collectively then add toward meeting the broader, larger goal.
When mapping out the requirements from stakeholders to elements, you may want to employ a requirements traceability matrix. This is a helpful tool when mapping out what the stakeholders want in terms of requirements such as business, functional, testing, security, and so on. We want to make sure that we meet the expectation of the customer or sponsor in terms of all the different viewpoints.
According to the traceability matrix, we want to demonstrate across the four issues how we are meeting the sponsor’s requirements. We document and map against what they say that they want with what we have done to meet their requirements. This is to help make sure that all the stakeholders are matched up to the requirement and that we demonstrate and document the results showing we are meeting their expectations. A tool can be used to help the customer to make sure we really understand and that they have given us really good requirements, that they truly represent what they need. This tool is called a Protection Needs Elicitation (PNE) and it helps the customer to articulate and more skilfully designate their ideas into a more manageable, logistical reality. It’s a protection in a way to help them to help us, by finding ways to probe and ask deeper questions so we may get good information and lets us understand better how to approach the client and acquire good information for the development of the software. It also helps us to better prioritise the different needs of the customer, how we are going to get the IFPP (information protection profile), conduct least privilege, threat analysis and most importantly, get the customer to sign off on the task being completed.
Customer verification is important because we have to assume that the collection of the requirements of all those involved and so forth are all totally correct because then, this data set is the basis for which nearly everything else that comes after. So, we need to make sure that we have a good, solid foundation so we can then move on.
The use and misuse situation is where we have something in place and because it’s there, is vulnerable to attack. For example, a username and password is what we use to identify and authenticate the user. However, an attacker can misuse that same information in a force attack to gain authentication. This goes into making sure that we are matching our requirements and also you will want remember about potential threats and vulnerabilities to prevent the misuse of our product, as well as improper use of it as well. So, this mitigation on keeping your product safe from forced attacks especially of those attacks associated with authentication or other parts of our product.
Classification of data is showing that there are two main forms and they are either structured or unstructured. Structured data is like when you are examining data in a database and nicely ordered. Whereas, unstructured data is more like images or videos and so not quite so orderly in the way the data is arranged. There’s various levels of security based on what classification of data we’re talking about. One level of security is the MAC environment. MAC stands for mandatory access control where there’s varying labels, subjects, and objects and these are what makes it possible for MAC to grant a higher level of security. The subject’s label must dominate the object’s label.Within this MAC environment, there are two roles: data owner and data custodian. The data owner is what determines the classification in the first place and the data custodian enforces the protection via backup and redundancy of the data.
So, in this module, there’s been discussions over the requirements and how to gather them from our customers, SMART requirements and gathering meaningful, specific requirements of the stakeholders and/ or customers so that later as we move on into the design and implement phase then we have a solid foundation and meet the needs of the client, based on what we have gathered and questions we‘ve asked to ascertain the product’s dimensions. This concludes Module 2. We’ll move on to the design and implementation phase in the next module.