Requirements development and requirements management both involve many different tasks. The ones that we're going to be focusing on are elicitation, analysis, specification, and validation. Specifically in this lesson, we're looking at elicitation. How do we elicit? How do we make this easier on ourselves and for our customers? First, we need to look at the overall roadmap for requirements engineering. Remember, our goal is to make software requirements. A software requirement is a software capability needed by the user to solve a problem to achieve some objective. Some of our software capabilities need to be possessed by a system or a system component. They may need to satisfy a contract, some standard, a specification, or some formally imposed documentation. So how do we get started in software requirements engineering? The very first thing is just to understand the problem. That is easier said than done. We have to wade through the entire problem domain. Our responsibility is to understand the stakeholders' problems, culture, language, overall needs, and figure out how all of those apply into the product. Normally this will start with us talking with the customers and the stakeholders. Sometimes these are too far removed. We don't have access to them. We can't talk to them. They don't have time for us. And it's just challenging to talk to people and actually connect. Remember though, that customers are people who are individuals or organizations, who derive direct or indirect benefits from the product. Usually our customers we consider as our project stakeholders and our product users. We also have senior managers, hirers, business people. These are people who are establishing project vision, product scope, defining the business requirements, and also paying us. So we need to keep all of these people in mind. Another set of users that we have are end-users. This is another smaller category. End-users are the people who are going to be using the product directly or indirectly. End-users are helpful to us in requirements engineering and requirements gathering because they can describe the tasks that they need to perform. They can also describe some of the quality characteristics that they expect. A challenge here though is that with end-users, and customers in general, will give you some vague statements that can be conflicting. For example, someone might say, well, the system has to be fast. It has to be running at all times. Downtime is going to ruin my ability to work. Having a fully reliable system in this way, likely not possible. How much do they really need? On the security side, you will have people saying, well, it needs to be secure. But I don't want to jump through hoops in order to get into the system. Well, what is jumping through hoops? Do you need to log in? Do you need to check your cellphone? Do you need to check your email? How do you do it? What is jumping hoops? Also, what level of security do they actually need? Business requirements may also go against your end-user desires and they need to be negotiated. Business requirements are different from business rules. That is important. Business rules are covering regulations, policies, formulas, events. They are needed to define constraints and give you definitions. Business requirements on the other hand focus on what the business people, the money people, what they want. You need to look at both of these. They both come into your requirements. The user requirements from all of these groups will help you to see how people really need to use the product. So business people, end-users, the people giving you the money, all possible customers, all the people who are pressing the keys, and so on and so forth. Once stakeholders on the business and user side have been identified and questioned, then we can move on to finding solutions that are firmly stated. For example, you can start determining actual requirements, such as, the car should have power windows, the search will return a list of outbreak locations, the program will allow web-enabled entry of sales orders, and so on and so forth. The goal is to create a feature set, then gain customer agreement. Many of the features may still be vague at this point. But you're starting to get a general idea of what is wanted. We do this from two different angles. From artifact-driven elicitation and also from stakeholder-driven elicitation. These will be discussed in future lessons.
