CSC 648/848-04 Summer 2021 Milestone 1: Use cases, High Level Requirements and Specifications Announce: 06/10/2021 Due: 06/22/2021 Objective: The objective of Milestone 1 is to develop: a) initial high-level personas and use cases; b) from use cases develop high level functional requirements for the application, c) list high level architecture, frameworks and tools to be used (generally the same as in M0), and c) get the teamwork going. Note that these are only high-level requirements and specs with the idea to get early feedback and iterate before investing in developing more detailed specs and first prototype in Milestone 2. Future designs can deviate from Milestone 1 in the spirit of iterative SW design and development. Initial input for your work is the instructor guidance, class slides on the topics as well as your SW and tool selection for M0. For use cases and functional specs, feel free to also use your own ideas, research similar applications that already exist, talk to your friends etc. Please consult class material on Use Cases, Requirements and Specs. This is the first team milestone. The whole student team submits one milestone document for each Milestone 1 – 5, submission details are below. You will discuss ongoing work on Milestone 1 during team session in each class, and you can also send e-mail to instructors with questions. Expected size of this document is at least 10 pages. Document formatting (page numbers, table of contents, each section starts in a new page….) is really important when you submit technical documentation like the one in M1. Content and structure for Milestone 1 document for review: In the document for Milestone 1 (M1) you must have ALL of the following subsections in exact order as below (have a separate numbered section for each) in one PDF file. I require that each subsection starts on the new page: 0. Title page MUST include –“SW Engineering CSC648/848 Summer 2021” Project/application title and name (you can use the name you chose for your application) –Team number –Names of students (team lead first) with e-mail of team lead. Please mark those who are team lead, front end, back end leads and Github master –“Milestone 1” –Date –History table (revisions) (Note: you will update this document based on instructors’ feedback so this is important) 1. Executive Summary: Short description of the final product/application and its key advantages, novelty, value (up to 1 page). Make it as an executive summary – think of answering the question of why we should fund this project. We suggest you assign a name to your project for easier reference and good “marketing”. This summary should be readable to a general manger/executive that is not a CS specialist and is used to explain and also to advertise/promote your project. Typical outline is: one paragraph on the motivation and importance of the application you are developing, followed by a paragraph on what your application will be doing and how it helps the users (high level only, no jargon) and optionally what is unique and special in your design. 2. Main Use Cases: Summarize key categories of users/actors for your application – their general characteristics, goals, skills, pain points related to the application you are developing. About 1/3 of a page per actor – see class notes. (Note: in key categories you stay general, in use cases you say how actors/users will use your app (at high level)). Then provide 5-10 main use cases (one paragraphs for each use case) - see class notes on more detailed format for requirements. Focus only on main use cases. For each Use Case you develop, first create it in text format, and then describe it using a Use Case diagram. Don’t forget to add in your user cases possible situations where the user or/and your app/actors do not perform actions as expected. Then, describe a possible solution. (see class slides) – tell us a story about who and how the application is used. Focus on WHAT users do, their skill level, not on HOW is the SW implemented. NOTE: avoid specific on HOW functions will be done and text resembling user manual: this is supposed to guide the design of the future product and is NOT a description of how the product will work (you don’t know that yet) – see class slides for details. Please assign a descriptive title to each use case so it can be tracked. 3.List of main data items and entities - define main terms, data structures and “items” or “entities” at high or logical (not implementation) level (e.g. name, meaning, usage, and NOT how the data is stored in memory) so it is easier to refer to them in the document. Focus on key terms (main data elements/records used in your app, types of users and their privileges etc. These terms and their names must be used consistently from then on in all documents, user interface, in naming SE components and database elements etc. In cases where you attach behavior and privileges to data items (e.g. user types) that also drives the design of the SW. In later milestones you will add more implementation details for each item. You will later expand this section with more details. This will help define planning and design for the DB for example. 4.Initial list of functional requirements – see class notes. This refers to high level functions you plan to develop to the best of your knowledge at this point. Focus on WHAT and not HOW. Keep the user in mind. Develop these functions to be consistent with use cases and requirements above. Number each requirement with unique numeric value and use these numbers consistently from then on. For each functional requirement use 1-3 line description. At this stage no need to prioritize the requirements. I am looking for at least 50+ or so functional requirements. 5. List of non-functional requirements (performance, expected load, security requirements, storage, availability, fault tolerance…). Note that mandatory high level non-functional specs are given in high level document, so for M1. Please observe and adhere to these non-functional requirements in your design and development from now on – you are not allowed to change them unless you get permission. Try to modify or adapt them to the non-functional features of your project. Non-functional requirements cannot be modified without the permission of all the teams involved in the project not only the engineering team. For instance, the engineering team needs permission from the marketing team in order to modify a non-functional requirement from the product, 6. Competitive analysis: Find five competitive products. Present competitors’ features vs. your planned ones. First, create a table similar to the one found in the ‘Competitive Analysis For Software Products’ slides. In this table, you will identify important features of all the competitive products similar to the one you are about to implement. Then, create a table with key features of competitors vs. yours planed, only very high level, 5-6 entries max (as shown in class). After the table, you must summarize in one paragraph what the planned advantages are or competitive relationship of your planned product to what is already available. In the table clearly mark your product, e.g. shade its column/ data. Take into consideration that your product must implement at least one unique feature/functionality/service that other similar products do not have. Also, it needs to improve required functionalities that all thee products share in common. 7. High-level system architecture and technologies used: Briefly provide itemized list of all main SW components such as frameworks, APIs, tools and systems to be used, supported browsers and deployment platform (SW and server) to be used. This list is to be the list of approved tools and systems from M0 (which may be the list you have modified during or after M0 – but get it approved). Any other external code/API/tool must be approved by instructor and you have to justify it. 8. Checklist: for each item below you must answer with only one of the following: DONE; or ON TRACK (meaning it will be done on time, and no issues perceived); or ISSUE (you have some problems, and then define what is the problem with 1-3 lines) • Team found a time slot to meet outside of the class • Github master chosen • Team decided and agreed together on using the listed SW tools and deployment server • Team ready and able to use the chosen back and front end frameworks and those who need to learn are working on learning and practicing • Team lead ensured that all team members read the final M1 and agree/ understand it before submission • Github organized as discussed in class (e.g. master branch, development branch, folder for milestone documents etc.) 9. List of team contributions: each student individually (including the team lead) must send an email to the class instructor with their contributions done in this milestone. This email must cover the following: • Detailed list of contributions made by the sender. • Complains that the sender has about other members of the team. (e.g student X was not showing up in meetings and doesn’t deserve the same grade than the other members of the team). The class instructor, once he receives all the emails from each member of the team, will forward all this information to the team lead. Take into consideration that complains will stay anonymous and only the class instructor will know the source of the complains. The team lead will receive the complains but will never know the name of the complainer. That way, I can ensure that complains are anonymous and honest. The team lead, after receiving the email from the instructor, must attach all the info received to this section of the milestone. Background reading: • Document instructor posted about high-level vision of our application (use cases, requirements and specifications slides) • Class material on requirements and specs • Relevant existing applications and products. • Info about allowed frameworks – class notes and posted on iLearn • M0 document and documentation on SW tools and frameworks you plan to use • Git and Github tutorial Submission for Milestone 1 document for review – you must follow the instructions below PRECISELY: Teams must collaborate in creating M1 document by having working M1 document on their team Github private repository (similar to managing code) so all team members and thee instructor can access it. Your team repository must have a root folder ‘milestones’. Inside the folder milestones, you should have 6 folders (M0, M1, M2, M3, M4, M5). Each milestone directory will have 2 versions of your milestones. We strongly suggest the following collaborative approach for creation and completion of M1 document (NOTE: creating a team document is similar to creating a code by the team of programmers): - Team leads assigns M1 editor - Team lead/M1 editor assign individual chapters to team members - M1 editor collect chapters, edits/corrects then integrates them into a well formatted document (with same font and formats) - M1 editor posts final candidate full document on team repo so that all team members read full document for one more review and any feedback - M1 editor completes the final version as per feedback - Team lead submits M1 info for review as per submission instructions. Submission instructions (below) must be followed precisely and completely or grade penalty will be imposed Note that it is strongly recommended that all members of the team work together in executive summary and use cases sections at the same time. That’s it, do not split work when working in those sections. That is the best way to create good quality and synchronized work that will be used later to extract good high level requirements. The whole student team submits one milestone document for M1, as follows: Team leads will send e-mail with a link pointing directly to M1 Document (in PDF) in your team repository (NOT the attached file) to jortizco@sfsu.edu Submission e-mail subject line: MUST be “CSC648-848-04 Summer 2021 Milestone1 Team NN” in the subject line (NN is a team number 01…07). File name of the M1 document in PDF (to which the link is pointing) to MUST be: M1v1TNN.PDF (NN is your team number) (We use only PDF so I can send you feedback as yellow sticky notes). Submission must be done by the deadline specified, any extension has to be approved at least 24 h ahead of the deadline. M1 document format and structure Team leads and M1 editors: make sure document is well formatted, reads well, is complete, and looks professional. This will be part of your portfolio and will influence the grade. Make sure all team members read final version and give comments before submission. Instructor’s feedback and creating final Milestone document for Final Project delivery In the course of developing M1 you can ask instructor questions via e-mail and during team session in the last hour of the class. Upon submission of Milestones you will get feedback from instructors by any of the following: e-mail, markings on your document and in class during team meetings. This feedback must be analyzed and taken into account by your team in order to revise your M1 and this must be used subsequently for the rest of the project. Please enter the revision summary in history table. Instructor will comment from the standpoint of CEO, VP of Marketing (who translates customer and marketing requirements) and CTO (Architecture etc.). You may choose not to agree with the comments. This is OK as long as you justify this and are prepared to live with that design and deliver it. In some cases, instructor may insist on some features or decisions. Upon getting instructor’ feedback on your questions and submitted document, you need to revise your first draft, freeze it (meaning no more changes on this document even if future design changes) and use it as a basis for developing Milestone 2 (M2). You can apply your modifications to the second version of each milestone.. Do not start working on M2 before you get feedback on M1 and make sure all team members read M1 V1 feedback provided by the instructor. Future M2 functions and actual SW app may differ from what you proposed in M1, that is normal and in fact expected to happen in the spirit of iterative SW development. Evaluation, feedback and grading I will provide feedback to your version 1 of each milestone only when all the sections are completed. Milestones with one or more incomplete sections will be returned, not feedback will be provided and points will be taken off from the final grade of this milestone. You won’t be able to move to the next milestone until you review, address and apply the feedback from the instructor in V2 of the milestone. For instance in this milestone, after you submit your M1V1, the instructor will provide feedback and the team will need to address the feedback in M1V2. At the end of the semester, I will grade only all the V2 from each milestone. Milestones improperly submitted will first be returned, and if problems persist 10% penalty will be applied to the grading of that milestone for that version. Only one error in submission in M1 will be “forgiven”, any subsequent problem submission in any milestone documents will be recorded with negative points under the rubric SE Process grade: submissions. Milestone documents have to have all required sections completed or negative points will be recorded for later grading (rubric: SE Process grade: document quality). Milestones have to be submitted on time and in a way as specified above. In case of justifiable reasons to delay, permission has to be obtained by e-mailing to Prof. Jose Ortiz jortizco@sfsu.edu 24 hours prior to the deadline. Late submissions with no permission incur 10% penalty on the grading of that milestone.



































































































































































































































学霸联盟