Before we actually move into how to elicit requirements, both from the stakeholder and from artifacts, we need to consider one more software development lifecycle that's becoming very common and it's certainly a buzzword. This is the Agile development lifecycle. In the Agile development cycle, iterations involve the customer before the product is completed. This reduces the chance of misunderstandings. However, in that Spiral model, if you have iterations that are 6 - 24 months long, there are plenty of time and space for customers to change their minds. They get new ideas. They have new needs or they just change their minds. You also run into the issue that they get excited about the product and come up with lots of new ideas. This leads to something that we call scope creep, but we'll get into that later. You can think of the issues that we have with the Waterfall or Spiral model, as it was off of the famous Dr. Seuss rhyme, the users exclaimed with a laugh and a taunt, it is just what we asked for but not what we want. So because of these issues back in 2001, 17 engineers came up with the Agile manifesto and the manifesto included four theses. Just like Martin Luther nailed his 95 Theses on October 31 back in 1517 to the door of the catholic church, which sparked the reformation movement on Christianity, these four theses defined a new concept of software development. Credit there are different levels there but it did make a huge change to how we develop software. Within the Agile process, you focus on individuals and interactions rather than processes and tools. You also focus on working software rather than comprehensive documentation. Customer collaboration is vital and you focus on that rather than contract negotiation. Another big thing about the Agile manifesto is that it's saying that we need to be able to change quickly rather than following a very set plan like we did in the Waterfall model, the Agile development cycle changes how we look at requirements and everything else within the software development lifecycle. We have more communication with users. That's probably the biggest part. This is one challenge that we have that is hard to get over. For any of you who have worked with customers in the past and worked on living software, how many times did you really see your customers? You all have time constraints, you have meeting constraints, you have differences and it becomes very very challenging. In Agile, we try to create documents but at the same time that is not the emphasis. The emphasis within requirements is to have customer collaboration rather than the contract negotiation and working software rather than comprehensive documentation. So there are many companies out there now saying we want Agile, but we still want all the documentation and so you come up then with a weird mix between basically the Spiral Model and the Agile approach. Remember that Agile's impact on requirements is like you do have more communication with your customers, you have less documentation and it's usually written in a different way. But, on a great side, the more you can communicate with your customers, the more you actually learn and that allows you to move forward. So we've talked about elicitation and the players that need to be involved to discover the requirements throughout the project. We need to first start by understanding the main ideas. Part of this is understanding the business vocabulary. You can't just talk to your customers in technical jargon. You need to be willing to learn and be willing to learn to understand. You need to get the customers and you need to understand what their requirements really are. Also remember that they probably don't fully know. Be very respectful. Explain all of the work products that are being created from the requirements process. As you are discussing ideas, you can also provide some other ideas. Mention some other alternatives. Something that could be very costly for you to implement, could be solved in a much easier way. Also, no matter what software engineering process you're using, when your requirements change, be honest about the changes. The changes are going to include possibly materials, possibly costs and other things. So look at yourself as the analyst. The analyst also serves as the main link between the customer community and the development team. Some of their responsibilities include gathering requirements, analyzing those requirements, documenting those requirements and validating them. With all of this, you're also likely working with the team. As we all know, teamwork is frustrating. So, you will also have to work with your team to determine who goes where, who got the correct requirements. Keep the requirements development alive. Keep moving forward. Manage activities as the requirements change. As you and your team work together, you will have many insights. As you work with the development team, the development team will maybe say this isn't possible and you have to go back and come up with alternatives and put all of this together. So, next, we'll see other roles that you as an analyst will play and what needs to be done. How do we actually elicit requirements?
