Next, let's consider how we build our requirements. We need to form user requirements and business requirements. Between these two, we then build the functional requirements of the system. The actual requirements of rewrite should have a number of properties. Remember that requirements are supposed to fully describe functionality, they contain all information needed for the developer to design and implement that functionality. If you don't know market to be determined put it in red, put it in bold, mark it in some way. In your software requirements specification, you must accurately describe the functionality to be built. In describing the functionality, you also need a reference for correctness so that you can relate your requirement back to the source of the requirement. Who did you work with? Who did you negotiate with? Who were those stakeholders who were affecting your decisions on that requirement? Each requirements statement should be possible to implement within known capabilities. They also should be able to work within limitations of the system within the environment. You may not know all of this information, that means that not only are you working with the customers in the situation, you are also working with the developers. The developers can tell you the limitations, the other abilities, and what you can really do. They can also help you to find alternatives. Every single statement should originate from an authority. That authority should be a business level person or a set of customers. The relevancy of the requirement is also very important. The feature or requirement should add value to someone. In these qualities, wording is very critical as many will be reading these requirements, potentially both the customer and the developer sides. There needs to be single consistent interpretation. It is very challenging to determine all needs fully during elicitation and make sure that everyone's happy. And face it, not everyone is going to end up happy. However, another point, another desirable quality that we need for our requirements is that the requirement is measurable and verifiable. Think, can I create a test that can either be verified by a human or can be verified automatically? For example, the statement, I need email sending to some recipient to be fast, it's vague, it's not verifiable. One way to restate it would be to say, the email should be sent and confirmed as sent within 5 minutes. In addition to all of these important desirable qualities for statements, the specification overall needs to be complete, consistent, modifiable and traceable. So, that's it, great. You ask questions, you get answers, you write it up. Easy, not so much. Elicitation of functional and nonfunctional requirements such as security, brings up many challenges especially the nonfunctional requirements. Before we get into nonfunctional requirements, we need to think about who we talk to, when, how do you balance responses, how do you negotiate and find alternatives, how do you balance risk. With risk analysis comes the security issue. In many situations, people will say, "I need my system to be really fast, but it also has to be very secure." First, that statement I just made was really vague. But note that when we're balancing security and performance, it all comes down to what's more important, it is totally a balancing game. This game varies depending on how and when you elicit requirements. And in our next sections, we'll discuss some of the ways that we go about eliciting requirements, and how this fits into the software development process.
