Assignment 1

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.


  • At this point in the project, the work is very open-ended, and the deliverables, artifacts, and documents you would create are quite dynamic. The deliverable this week is also quite flexible. Provide an overview of the business or organization. Define your methodology and document your findings so far based on how you have chosen to elicit requirements. Do this within the template provided for the Key Assignment template provided here.
  • If you are using modeling techniques, include the diagrams within your Word document with appropriate text descriptions to back up and give context to the diagrams. If you are conducting meetings (real or imaginary), capture the minutes and conclusions you are finding from the meetings. Every requirements elicitation methodology's goal is to start to find order from the chaos of information that is the start of a project.

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.

Assignment 2

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).


You can use any use case template you see fit or have found on the Internet. It should include at least the following sections:

  • Preconditions
  • Primary flow
  • Exception flows
  • Alternate flows
  • Post conditions

There are other sections most likely to include (e.g. business rules, included actors) but again, you choose the methodology you wish to follow.

Assignment 3

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.


  • For Phase 3, you must add to the Key Assignment requirements document. You can access the updated Key Assignment document here. You have started a full set of functional requirements using a traditional requirements technique of your choosing. Describe the methodology you will use to capture the requirements. Identify the general rules you will follow for identifying requirements and how you will document them to allow for traceability going forward to design and test.
  • Then, document the functional requirements for your system assuming the traditional requirements technique you are using is the only source of requirements. You can use information from your use cases as an input to the requirements, but you should not refer to them here, and the final product should be a standalone contractual set of all the features needed. At the end of this Phase, you will have created two sets of functional requirements for the same system, one via use cases and the other using your chosen traditional technique.

Assignment 4

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.


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):

  • Review Participants (who will participate based on your chosen project)
  • Quality Requirements Criteria (what should be there or not there)
  • Requirements Change Process (how you will update after the review)

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.

Assignment 5

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:

  • Performance
  • Security
  • Safety
  • Legal
  • Supportability
  • Usability
  • Reliability
  • Infrastructure

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:

  • Who are the key participants involved?
  • How are elicitation approaches conducted?
  • What is primarily captured as a result of elicitation techniques?

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:

  • Will you follow one of your described methodologies?
  • If so, why did you choose that one above the others?
  • Will you blend elements of each?
  • What is the advantage of using more than one?

2. (Will provide peer information on 5/25)

Consider and answer the following:

  • Did both you and your peer capture all of the people who may be a part of the elicitation effort? Is there some role that either of you forgot?
  • How does your elicitation method differ from your peers? Is it complementary in some way where you could do both?
  • What will you apply from your peers method into your own approach in the IP?

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.

  • Before use cases, what other methodologies existed to formally document requirements? What language and techniques were used to capture requirements? How did requirements traceability impact the way people document requirements? Where do contractual obligations impact how we capture requirements?
  • Some projects will write use cases but still have formal documentation techniques past use cases. Why do they feel this is necessary? What information is captured within use cases, and what is captured in other techniques? What does the process look like? Do they work together (complementary) or feed into each other? What is the final source of truth for defining behavior if one supersedes the other? There are most likely many ways to do this, so describe an example methodology you find.
  • Use cases describe an interaction between users and systems, but traditional techniques view requirements as almost a third party describing what is needed from a system. What tricks and tips are there for writing traditional style on traditional requirements? What qualities are desired in these requirements?

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:

  • Performance
  • Security
  • Safety
  • Legal
  • Supportability
  • Usability
  • Reliability
  • Infrastructure

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.

Academic Honesty!
It is not our intention to break the school's academic policy. Projects posted are only used as a reference and should not be submitted as is. We are not held liable for any misuse of the solutions. Please see the frequently asked questions page for further questions and inquiries.
Kindly fill out the form. Please provide a valid email address and we'll get back to you in less than 24 hours. We will be sending an invoice through PayPal upon confirmation. We are a non profit organization however we need an amount to keep this organization running, and to be able to complete our research and development.