Within this week's Discussion board , you have chosen a technique to further refine your requirements. You are being assigned to work on capturing requirements for 1 of 2 projects (your choice) this term. This week, your first task is to familiarize yourself with the business or organizational need and use the elicitation technique(s) you described to capture more information in anticipation of writing requirements the next few weeks.
Deliverables
This week, you need to show how you would capture that information before leading into requirements definitions the next few weeks. Your assignment should be 35 pages of information, though it may be longer if it includes detailed diagrams or pictures.
Within the Discussion Board, you defined the use cases that are needed for your system. Given the information you gathered in the Phase 1 elicitation, you have enough information to fill out the use cases in detail and add them to our Key Assignment template started in Phase 1. For this IP, you will be continuing your requirements document by filling out all of the details of a use case document in a template for each use case defined (at least 3, but feel free to stop at 4; if you found more, pick the most interesting 4. Do not limit the analysis though if you see more than 4 use cases).
Deliverables
You can use any use case template you see fit or have found on the Internet. It should include at least the following sections:
There are other sections most likely to include (e.g. business rules, included actors) but again, you choose the methodology you wish to follow.
In the Discussion Board this week, you have researched how different companies document requirements, sometimes via use cases but often also including other traditional techniques or only these traditional techniques. Using your research and that of your peers, you are going to practice the traditional techniques for capturing requirements. The good news is you likely have much of the information you need from the research conducted in Phase 1 and the use cases written in Phase 2.
Deliverables
For the response phase of this week's Discussion Board, you are being asked to review your peers work. Requirements reviews may be conducted informally (like you are doing here) or with structured meetings and roles and set participants. Either way, there are certain criteria by which the quality of requirements are judged.
Deliverables
As you are preparing to conduct your review, we want to capture the process and criteria by which you will be judging the quality of your peer's requirements. Your focus will be on the use cases and functional requirements from Phase 2 and 3. To help with this, capture the following information in the Phase 4 section of your Key Assignment Document (found here):
Finally, based on the feedback you receive from your peer(s) in the Discussion Board, integrate any changes you feel are needed. Use your change process to show how you included the recommended changes. If you do not receive feedback, demonstrate your change process and how you would integrate a change by including a change you decide or by adding new requirements.
To complete the requirements, you need to consider not only the features and functions the system will provide to the user, but other elements that are key to the operations of the system. Even if your application provides amazing features, users will not want to use it if it is slow. Your company may lose customers if they do not feel their data are secure. Your solution may provide cost savings internally for one group, but the lack of a plan for managing operations (data archiving, password management, patches and upgrades, etc.) can cause unexpected costs that may not be properly budgeted.
The last step for your requirements is to capture these nonfunctional elements of requirements. Not all systems are built alike, and the nonfunctional requirements may be based on the point in time the system is being created. Thus, there is rarely a common set of features or rules by which you can find or document the nonfunctional needs of a system. In this last step, you will need to capture whatever mix of nonfunctional requirements your chosen project and the conditions (customer and needs) you are imagining. Complete your requirements by providing a set of nonfunctional requirements that cover several of the aspects you will find in your research, including, but not limited to, the following:
This being the final submission, make sure you have corrected all prior sections based on prior instructor feedback and that of your peers, and include any changes in your chosen change-tracking mechanism.
1. A first pass at requirements for a system is actually quite easy. Even the most informal of conversations can start the process and allow basic requirements to be captured. Without a deeper understanding of the needs and drivers of a stakeholder, however, it can be insufficient to start the process of creating a successful system. Fortunately, decades of information technology (IT) work have developed tools and techniques for eliciting requirements.
Before you start capturing requirements of your own, take some time to document at least 3 formal approaches to requirements elicitation, including the following:
After describing each of the 3 in detail, describe how you will conduct your requirements elicitation for the product to be built in the IP for this course. Discuss the following:
2. (Will provide peer information on 5/25)
Consider and answer the following:
3. Your main task is to create a use case diagram for the system you chose to implement in Phase 1 of this course. The diagram should include all the user roles, if applicable, the multiple systems and interfaces to be built, and at least several use cases (log in and other security do not count; look for business operations). The diagram should be included in a Word document or otherwise attached to the Discussion Board as an image.
Along with the use case diagram, provide a brief description (a few sentences to a paragraph) for each use case describing the basic functionality provided. This is not the entire use case, which will be constructed in the Individual Project. For now, you want to provide enough context to get feedback on if you have appropriately defined use cases from your peers.
4. (Will provide peer information on 6/1)
After submitting your use case, choose a peer who has not received feedback (they do not have to have selected the same project as you to implement). Consider if their use cases are appropriately defined, and if so, describe why you think they are well-formed. If you think the use cases are not accurate, provide feedback as to how you would improve or restructure the definitions. You must provide feedback for each use case defined individually as to what makes it a solid definition or how it can be improved. Finally, consider if they did indeed cover all needed features (are they missing a user role or a use case?). If so, provide this last bit of feedback, as they will need the best picture possible before starting the Individual Project.
5. For this Discussion Board, pick 1 of the following topics and elaborate on the subject while answering the question. This is your chance to do some focused research and report back to the class and share what you have found for the benefit of all.
Look to address a topic that has not been answered yet, but also something that interests you. Try to address the ideas behind all the questions in the topic, but do not feel that you must answer each one individually. The goal is to dive into some unique aspect that one of your peers may not, and thus the class will learn a bit more from all of the posts together.
6. (Will provide peer information on 6/8)
For your response, choose 2 peers who have not yet received responses and, if possible, chose topics different from each other and from what you chose. Identify what new information you have learned from your peers research, how that information may apply to your research, and how you can use that information in your requirements documentation going forward.
If applicable, adhere to APA guidelines when creating in-text citations and references. Your assignment should be free of grammatical errors, use complete sentences, and give specific details that support your statements.
7. For the initial post, you simply need to publish your most up-to-date work from the three previous weeks with feedback integrated from the instructor's grading (as available given the initial posting deadline). Do not forget to add in change tracking, as described for the Individual Project this week, before you start making changes. Let your work speak for itself simply by attaching the Key Assignment document.
8. (Will provide peer information on 6/15)
The rest of the week, prepare for your review by looking at the work within your Individual Project. Use the criteria and anything else you choose to document to conduct a review of the requirements of one other peer, preferably someone who has chosen a project different than you. Review Phases 2 (use cases) and 3 (traditional functional requirements), not the elicitation details from Phase 1, though that information may help inform you if the generated requirements.
Your feedback should be substantial and reflect both the positive qualities of the requirements as well as any improvements or suggestions. It is essential you capture both what your opinion is and why, as the instructor needs to see your justification to show that you are valid in your opinion.
9. or this Discussion Board, research at least 3 different aspects of nonfunctional requirements from the following list or other findings from your research:
10. (Will provide peer information on 6/22)
After defining the areas, provide several examples from your category. You can use the domain you are researching because you will be defining these requirements in the IP, or you can use generic examples to describe the ideas for now. The goal is by the end of all discussion contributions to have all of the categories the class can think of be described, so try to pick at least one that others in the class have not covered.