Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

MET CS682 ASSIGNMENT 3

TERM PROJECT PART 1:

REQUIREMENTS

The purpose of this exercise is to get practice of specifying requirements. In practice, requirements are uncovered in an iterative process, with the focus of determining what users really want and need. This is your start. Go as far as your imagination allows, remaining aware of the fact that you are not necessarily specifying an entire system.

Please leave the headings and the gray text unchanged except for the hints section which should not be included in your solution. Observe the page limitations; however, you may include as many appendices as you wish. All appendices should be referred to in the main text. Include your last name in the file name of the assignment. (i.e. SmithM_CS682Assignment3.docx). Then, follow the example in Module 0: Executive Writing to format your assignment prior to submission.

You are to specify a system called BestPurchase- an app focusing on retail with automation and or recommendation capabilities.  We are not providing any more detail on purpose – which simulates the notion of trying to understand what the customer really needs and encourages you to set your own unique scope and functionality of the system from the rest of the project.

• You are setting the requirements for BestPurchase.

• Form your own vision and scope, as a starting point consider your own shopping experience and how an app might help improve this experience.

• It will be helpful to focus your thinking on a specific setting – for example, the app could be geared toward helping families with weekly supermarket shopping, or perhaps clothing and goods for the elderly – these are just examples, the scope and focus can be yours.  We do suggest making a link to your personal experience, or something that you have business knowledge and interest in, to simulate typical conversations you might have with end-users to understand what they want and need in a system. Leverage top down and bottom-up analysis outlined in the module to aid your thinking.

• Your solution should focus on software-intensive aspects, however, consider wearables and other IoT components.

• Consider the perspective of one or more actors within your system.

The last section on this template lists numerous hints.

1 Assumptions/Scope

In no more than a few sentences outline your scope. Provide a scenario and what your project will focus on.  A bulleted list is fine.   

Your response replaces this.

1. Overview/Mission Statement

One paragraph, about four to six sentences.

Your response replaces this.

2. User Stories

Provide two (2) user stories from two different types of actors (system users) in the format provided below. The two user stories should come from two different actor’s point of view. Replace all of the “<…>” parts.

1.1 First User Story

As a <type of user>, I want <some goal> so that <some reason>.

1.2 Second User Story

As a <type of user>, I want <some goal> so that <some reason>.

3. Functional Requirements

In about three quarters of single-space page (using 12-point type), specify a total of 10-15 key functional requirements. These requirements define your chosen scope within the whole system.  Each requirement is a single sentence.

Your response replaces this.

4. Use Cases

Specify two detailed use cases in the tables below which you consider important and complex to the functionality, showing actors, preconditions, actor actions, and system responses. Consider complexity for relevance and depth, as a use case would be used to understand something complex within your system. Each of these use cases should have approximately 5 to 6 steps, with each step potentially having an actor and/or system component.

1.3 First Use Case

Use case Name
Actor:
Description:
Pre-condition:
Step #	Actor	System
1
2
3
4
5
(more)
Alternate Courses:

1.4 Second Use Case

Use case Name
Actor:
Description:
Pre-condition:
Step #	Actor	System
1
2
3
4
5
(more)
Alternate Courses:

5. State Transition Diagram

Develop a high-level state transition diagram for the system. Select this so that it has meaningful states. Limit this to 5-7 states if possible.  Consider states beyond GUIs. Note that sub-states of one of these states will be added in question 6. You may use Draw.io, Visio, LucidChart, or another design tool of your choice (please check with your facilitator in advance if you are using a different tool).

Your state transition diagram and notes replace this.

6. Sub-States

Expand one of the states in the previous question into sub-states consistent with at least one of your detailed use cases. Limit this expansion to 4 sub-states.  Show the transitions that affect these sub-states.  You may combine parts 5 and 6 together into a single diagram for part 5 as long as it is clear.

Your sub-state transition diagram and notes replace this.

7. GUI Sketch

Create a GUI sketch of one important/complex screen of the system. You can use Draw.io, LucidChart, Visio, https://www.mockflow.com/, or another design tool of your choice (please check with your facilitator in advance unless you plan to simply insert screenshots).

Your GUI sketch and notes replace this.

8. Non-Functional Requirements

Specify what you consider the two most important non-functional requirements to implement this system specifically. Each requirement is a single sentence. Describe your choices briefly and explain why you consider these most important. Outside research and relevance to the functionality which was mentioned earlier will be important to supporting your ideas.  No more then 1/2 of page total.

Your response replaces this.

2 Appendix

This section is optional, place any notes here on how you have used the references or any other notes you would like to make.  

3 References based on Research

Show that you used a wide variety of resources by listing them below and clearly indicating in the body above where you used. Make sure to use proper referencing in your paper. We suggest using APA format, but other formats are fine as long as it clearly distinguishes your work from work of others in your response—be mindful of plagiarism rules.  

[1] your first reference replaces this

[2] …

Evaluation

 

Please do not include Hints section in your solution.

1 Hints

3.1 Overall Assignment Notes

• As usual, the notes are a primary source for explanations and examples; we also encourage you to do outside reading and research to gain additional perspective. In the real world, you would be interviewing people to carry this out but that is not possible in a class setting.

• If you run out of space (after careful editing), you may provide an additional explanation in the appendices section to support your design decisions or to clarify your choices.

• As in the real world, the quality of your work is subjected to judgments, not mathematical exactness. Help your facilitator make favorable judgments by being as clear and specific as possible. “Clarity” is one of the criteria.

• Feel free to include notes for your facilitator (that are not actually part of your paper). A good way to do this is to insert, for example, “Note 3 to facilitator” and list the notes in the appendix.

3.2 Notes to Selected Grading Criteria

Clarity:   Part of requirements analysis is to understand what your customer wants and needs (and, as we discussed, this is not easy)—so be sure that you understand the problem. Your response will be clearer as a result. Are your requirement statements clear enough so that someone could create a design from them? Are your names (e.g., of states) expressive enough so the reader can understand them? Explain throughout. Consistency (an aspect of clarity):  Make sure that your entire solution is consistent.  For example, did you introduce some functionality in the use case that you didn't mention in your functional requirement?  Then go back to part 3 and make sure to revise it.

Relevance: Review the scenario and make sure to stick to it.  If you need to expand on them a bit that’s fine; provide a brief introduction with your assumptions, but make sure to stay within the initial framework of the scenario.  For example - it's best to describe your approach and/or scope for the diagrams.

3.3 Mission Statement/Overview

Technical Soundness:

• A high level overview. Logically, one would write this first, and then the other parts would flow from it. However, our minds do not necessarily operate very logically. To stimulate your thinking about the mission, you may first want to think about a user story, or even just an actor.

• Avoid details—they come later.

Clarity

• Do not underestimate the time required to write a clear overview that is both short enough to be readable, and yet long enough to convey what the system does, structured appropriately.

• Come back to this section at the end, to make sure it is consistent with the rest of your solution.

3.4 Functional Requirements

Clarity

• You do not have to go into the finest details of the requirements, but make sure that you describe the major functionality. Enumerate and describe your functions systematically.

• Look to organize requirements with headers and sub-headers, for example by actor and or functional area.

• If a functional requirement sounds a little bit non-functional, explain your reasoning as to why you decided to keep it functional in a note (as sometimes these are borderline).

Technical Soundness:

• Make sure to understand the difference between functional & non-functional requirements.

· Functional: Reasons for the system and what it’s meant to do.

· Non-functional: Needed or wanted but not the reasons for the system.

Thoroughness and Coverage:

• You may need to come back to this after you complete the assignment to see what you missed, for example, are there key features you outlined in the GUI, state transition or use case which were not covered here?

Relevance:

• You may want to do some outside research to see relevant examples of how functional requirements are defined for systems. You can include your findings in the Appendices section

3.5 Use Cases

Technical Soundness:

• Complete the use case template we give you in the assignment.

• Additional information is available in the tabular-narrative forms of Figure 4-13 on page 143 of the textbook and in the “Use Cases” section of the Module 3 notes.

• The use case needs to show appropriate sequence (actor/system)

• Clear understanding in difference between constraints and pre-conditions.  The use case itself should follow one path as best as possible.

• Avoid branching in use cases, if possible—use only if necessary.

Thoroughness and Coverage:

• Complete the use case template we give you in the assignment. This is where we ask you to describe the use case, who uses it, what might be the pre-conditions, and alternate steps.

• Research can be applied by looking at similar systems (i.e. here is what I found and how it relates to my design). This makes your solution real and is something that analysts need to do to understand what technology will be used to implement this.

Clarity

• Consider consistency and relevance to the scenario.

3.6 State Transition Diagrams

Technical Soundness:

• A good place to start is to review the “State Machine and State Transition Diagrams,” “Components of State Transition Diagram,” and “State Transition Diagram—An example” sections in this week’s lecture notes.

• Consider your use case as a way to start thinking about state transition, ‘what the system does’ are the states of your system, and ‘what the actor does’ could be the events that trigger the transitions, and then look to functional requirements and user stories to add detail.

• Avoid focusing too much on use cases themselves, you want to capture the overall main steps of the system.

• Make sure all transitions are labeled with events.  If a state transitions into a state (i.e. search completed) but is not significant to be it’s own state, use it as an event within guard conditions.

• Please see pages 221-227 in the text on Behavioral State Machines – however, please note that this requires Object Oriented approach which we will look at next week. For now, review the mechanics of the state machine as it applies to this assignment.

Thoroughness and Coverage:

• Make sure all key functionality is covered (use cases, user stories, what was discussed in the system overview)

Clarity

• Make sure to show what the composite state(s) are, in other words note that these contain sub-states.

• Are diagrams clear to read (i.e. no overlapping lines, no non-polished designs)?  

• Diagram should be consistent with requirements (i.e. functional, use cases).

3.7 GUI Sketch

Relevance:

• Decide what is the most important, potentially complex screen, consider what it should contain and draw a rough mockup sketch.

Technical Soundness:

• See the “GUI Mockup Example” section in this week’s module for examples.

• Chapter 10 in the text covers material on human-computer interaction layer design.

• GUI is fairly straight forward; many students have fun with this.  As mentioned previously, Visio and Lucidchart have a wireframe template, but you can also check out balsamiq.com, wireframepro.com or mockflow.com

Clarity

• Provide “Sticky Notes” to describe functionality which may not be obvious.

3.8 Non-Functional Requirements

Technical Soundness:

• Make sure to understand the difference between functional and non-functional requirements.

• This is the "How" the system is implemented (i.e. quality requirements, constraints). Use references to support your choices. Think about what is most important and why; use of references should help here.

• The “Non-Functional Requirements” section of this week’s notes provide examples.

• Please see secondary readings for Week 3 in the textbook for additional examples of non-functional requirements.

Thoroughness and Coverage:

• You may want to do some outside research to see relevant examples of how non-functional requirements are defined for systems. You can include your findings in the Appendices section.

Relevance:

• Review your entire solution after completing it—you will uncover additional considerations. Check for consistency.