diff --git a/Glossary-Standard-Terms.md b/Glossary-Standard-Terms.md new file mode 100644 index 0000000..ed8c495 --- /dev/null +++ b/Glossary-Standard-Terms.md @@ -0,0 +1,481 @@ + + +# Standard Terms Glossary +--- + +**Process impact:** This file as a dictionary of standard terms defined +as they are used across projects. Individual projects should not need to +edit this file. Writing out the definitions of terms and acronyms here +helps keep other documents more concise and easy to edit. Check the +[ReadySET glossary](http://readyset.tigris.org/templates/glossary-std.html) for +updates. + +Jump to: [General](#general_terms) | +[Computer science & technology](#computer_science_and_technology_terms) | +[Process](#process_terms) | +[Software development tools](#development_tool_terms) | +[Requirements](#requirements_terms) | [Design](#design_terms) | +[Design goals terms](#design_goals_terms) | [QA terms](#qa_terms) | +[QA goals terms](#qa_goals_terms) | [Additional terms](#additional_standard_terms)| +[Project terms](Glossary#glossary) + + +### General Terms + +##### Chipping away +The process of removing sample text from templates when that text +does not apply to the current project. Often some of the sample text +will be kept or revised to fit the current project. Even if the +sample text does not fit the current project, it provides a reusable +example of how to phrase that type of description. The term +"chipping away" comes from an old joke: when a sculptor is asked how +he carved a marble statue of a horse, he replies "It was easy, I +just started with a big block of marble and chipped away everything +that did not look like a horse." + +##### Attached worksheet +The idea is similar to filling in an IRS form and using worksheets +to calculate subtotals or make specific decisions. That is to say, +there is a hierarchy to the templates: there are the main templates, +and then worksheets for specific topics. We have divided the +information into several files so that each file is focused on one +topic, and so that each file can be worked on by one person in a +reasonable amount of time. + +##### Process impact +The process impact box on each template explains where the current +template fits into the software development process. It usually +includes a brief comment on who should create the document, and who +would be expected to make use of it. You can change the process +impact box, but you should not need to. + +##### Checklist +There are two kinds of checklists: + +- Many of the templates have a section with questions that help + you check your work in that template. Often the sample answers + to the questions prompt you to take some corrective action. +- For design and code review meetings, there are links to + guidelines and checklists that help you identify common errors + in those artifacts. + +##### Sticky note +The idea is similar to a post-it note attached to a document that +tells you do "sign here" or fill in a certain part. There are two +types of sticky notes: + +- *TODO: Instructs you on how to fill in the template. This is the + minimum that you need to do. One of the main goals of ReadySET + is to help your team *quickly* carry out basic software + engineering activities. The TODO sticky notes make that easy by + making the templates more self-explanatory.* +- TIP: Helps you think of better ways to fill in the template. One + of the other main goals of ReadySET is to help your team make + better decisions that can make your whole project more + successful. The TIP sticky notes help with that. + +After you have done what the sticky note says, you can delete the +sticky note. + +### Computer Science and Technology Terms + +##### ::API (Application Programming Interface) +An API is a set of functions that one software component makes +available to other software components. That allows other programs +to "call" this program via direct function calls, or more indirect +communications such as [SOAP](#soap) messages. + +##### ::SOAP +SOAP (Simple Object Access Protocol) is the message format used by +standard web services. It entails sending an XML document to a +server in order to invoke an operation on the server-side. +[More information on SOAP](http://directory.google.com/Top/Computers/Programming/Internet/Web_Services/SOAP/?tc=1). + +### Process Terms + +##### Change Control Board (CCB) +A group of people who review proposed changes to the project +requirements and/or source code to accept or reject changes in each +particular release. Proposed changes are usually rejected if they +introduce too much risk or would trigger additional effort (e.g., +the need to redo a lot of testing on new code). A CCB is usually +composed of managers and representatives of other stakeholders such +as the QA group and key customers. + +##### Feature Complete +A release is called "feature complete" when the development team +agrees that no new features will be added to this release. New +features may still be suggested for later releases. More development +work needs to be done to implement all the features and +repair defects. + +##### Code Complete +A release is called "code complete" when the development team agrees +that no entirely new source code will be added to this release. +There may still be source code changes to fix defects. There may +still be changes to documentation and data files, and to the code +for test cases or utilities. New code may be added in a +future release. + +##### Internal Release Number +An internal release number is the number that the development team +gives each release. Internal release numbers typically count up +logically, i.e., they do not skip numbers. They may have many parts: +e.g., major, minor, patch-level, build number, RC number. + +##### External Release Number +External release numbers are the numbers that users see. Often, they +will be the same as the internal release number. That is especially +true if the product being built is a component intended to be reused +by another engineering group in the same development organization. +External release numbers can be different for products that +face competition. External release number are simpler, and may not +count up logically. E.g., a certain major ISP jumped up to version 8 +of their client software because their competition had released +version 8. Later, the competition used version "10 Optimized" rather +than "10.1" or "11". + +##### Release Number +The term "release number" by itself refers to an +[external release number](#external_release_number). Users normally are not aware +of the existence of any internal release numbers. + +### Development Tool Terms + +#### Version Control System +::DEFINITION1 + +#### Commit Log Message +::DEFINITION1 + +#### Issue Tracker +::DEFINITION1 + +#### Unit Testing Automation +::DEFINITION1 + +#### Automated Build System +::DEFINITION1 + +#### Source Code Analysis Tool +::DEFINITION1 + +#### Style Checker +::DEFINITION1 + +#### Source Code Formatter (Pretty Printer) +::DEFINITION1 + +#### System Test Automation +::DEFINITION1 + +### Requirements Terms + +#### Feature specification +A feature specification focuses on one feature of a software product +and completely describes how that feature can be used. It includes a +brief description of the purpose of the feature, the input and +output, and any constraints. Individual bullet items give precise +details on all aspects of the feature. One feature may be used in +many different ways as part of many different use cases. + +#### Use case +The main part of a use case is a set of steps that give an example +of how an [actor](#actor) can use the product to succeed at +a goal. These steps are called the "Main success scenario", and they +include both user intentions and system responses. One use case may +show how the actor uses several features to accomplish a goal. + +#### Actor +A user or an external system that uses the system being built. + +### Design Terms + +#### ::TERM2 +::DEFINITION2 + +### Design Goals Terms + +#### Correctness +This design correctly matches the given requirements. + +#### Feasibility +This design can be implemented and tested with the planned amount of +time and effort. + +#### Understandability +Developers can understand this design and correctly implement it. + +#### Implementation phase guidance +This design divides the implementation into components or aspects +that can correspond to reasonable implementation tasks. + +#### Modularity +Concerns are clearly separated so that the impact of most design +changes would be limited to only one or a few modules. + +#### Extensibility +New features or components can be easily added later. + +#### Testability +It is easy to test components of this design independently, and +information is available to help diagnose defects. + +#### Efficiency +The design enables the system to perform functions with an +acceptable amount of time, storage space, bandwidth, and +other resources. + +#### Ease of integration +The components will work together. + +#### Capacity matching +The architecture deploys components onto machines that provide +needed resources with reasonable total expense. + +#### Expressiveness +It allows for storage of all valid values and relationships + +#### Ease of access +Application code to access stored data is simple + +#### Reliability +Stored data cannot easily be corrupted by defective code, concurrent +access, or unexpected process termination + +#### Data capacity +The system can store the amount of data needed. + +#### Data security +Protection of sensitive user and corporate data from unauthorized +access or modification + +#### Performance +Data can be accessed quickly + +#### Interoperability +The database or data files can be accessed and updated by other +applications + +#### Intrusion prevention +Prevent, e.g., hackers opening a command shell on our server. + +#### Abuse prevention +Prevention of abuse (e.g., using our system to send spam). + +#### Auditability +All changes can be accounted for later. + +#### Understandability and learnability +Users can reasonably be expected to understand the UI at +first sight. Users will be able to discover additional features +without aid from other users or documentation, and they will be able +to recall what they have learned. + +#### Task support and efficiency +The UI is well matched to the users' tasks and it can be used with a +reasonable number of clicks and keystrokes. + +#### Safety +Users are not likely to accidentally produce an undesired result +(e.g., delete data, or send a half-finished email). + +#### Consistency and familiarity +Users can apply their knowledge of similar UIs or UI standards to +this system. + +### QA Terms + +#### Bug +*n.* **Deprecated** since 1991. See [defect](#defect). + +#### Error +*v.* A mistaken thought in the developer's mind. Often caused by +miscommunication or bad assumptions. Errors can create +[defects](#defect). E.g., a developer might erroneously think that +the square root of -4 is -2. + +#### Defect +*n.* The result of the developer's [error](#error) embodied in the +product source code, initial data, or documents. E.g., a square root +function which allows negative numbers as arguments is defective. +Defects can be removed by changing the source code, initial data, +or document. + +#### Fault +*n.* The execution of defective code. E.g., if a certain input is +provided to defective code, it may cause an exception, or go into an +infinite loop, or store an incorrect value in an internal variable. +A fault is not normally visible to users, only the +[failure](#failure) is visible. + +#### Failure +*n.* The user-visible result of a [fault](#fault). E.g., an error +message or an incorrect result. This is evidence that can be +reported in a defect report. Developers use failure evidence during +debugging to eventually find and remove [defects](#defect). + +### QA Goals Terms + +#### Functionality > Correctness +Correctness is the most basic quality goal. It means that, when +valid inputs are given and the system is in a valid state and under +reasonable load, the system's behavior and results will be correct. + +#### Functionality > Robustness +Robustness is the system's ability to gracefully handle +invalid inputs. It should never be possible for any user input to +crash the system or corrupt data, even if that user input is +abnormal, unexpected, or malicious. + +#### Functionality > Accuracy +Accuracy refers to the mathematical precision of calculations done +by the system. Any system that does numeric calculations must +consider accuracy, e.g., financial or scientific applications. + +#### Functionality > Compatibility +Systems that claim to follow standards or claim compatibility with +existing systems must adhere to the relevant file formats, +protocols, and APIs. The relevant standards are linked at the top of +this document. + +#### Functionality > Factual correctness +Is the data in the system a true representation of the real world? +Any system that contains initial data or gathers data about the real +world should be sure that the data is factually correct. E.g., a tax +preparation program should embody correct and up-to-date facts about +tax law. + +#### Usability > Understandability and Readability +Users need to understand the system to use it. The basic metaphor +should be understandable and appropriate to user tasks. Some defects +in understandability include unclear metaphors, poor or hard-to-see +labels, lack of feedback to confirm the effects of user actions, and +missing or inadequate on-line help. + +#### Usability > Learnability and Memorability +Every user interface contains some details that users will need to +learn and remember. E.g., Alt-F to open the "File" menu. UI cues and +rules can make these details easier to learn and remember. E.g., the +"F" is underlined and, as a rule, the first letter is usually the +accelerator key. + +#### Usability > Task support +This is the quality of match between user tasks and the system's UI. +Task support defects are cases where the system forces the user to +take unnatural steps to accomplish a task or where the user is given +no support for a difficult step in a task. E.g., must the user +invent an 8-character filename for their "Christmas card list"? +E.g., must users total their own tax deductions? + +#### Usability > Efficiency +Users should be able to accomplish common tasks with +reasonable effort. Common tasks should be possible with only one or +two steps. The difficulty of each step should also be considered. +E.g., does the user have to remember a long code number or click on +a very small button? + +#### Usability > Safety +Humans are error-prone, but the negative effects of common errors +should be limited. E.g., users should realize that a given command +will delete data, and be asked to confirm their intent or have the +option to undo. + +#### Usability > Consistency and Familiarity +Users should be able to apply their past experience from other +similar systems. This means that user interface standards should be +followed, and common conventions should be used whenever possible. +Also, UI elements that appear in several parts of the UI should be +used consistently, unless another UI quality takes priority. E.g., +if most currency entry fields do not require a dollar-sign, then one +that does demand it is a consistency defect, unless there is a real +chance that the user is dealing with another currency on that step +in his/her task. + +#### Usability > Subjective satisfaction +Users should feel generally satisfied with the UI. This is a +subjective quality that sums up the other user interface qualities +as well as aesthetics. + +#### Security +The system should allow usage only by authorized users, and restrict +usage based on permissions. The system should not allow users to +side-step security rule or exploit security holes. E.g., all user +input should be validated and any malicious input should +be rejected. + +#### Reliability > Consistency under load +Every system has some capacity limits. What happens when those +limits are exceeded? The system should never lose or corrupt data. + +#### Reliability > Consistency under concurrency +Systems that allow concurrent access by multiple users, or that use +concurrency internally, should be free of race conditions +and deadlock. + +#### Reliability > Availability under load +Every system has some capacity limits. What happens when those +limits are exceeded? The system should continue to service those +requests that it is capable of handling. It should not crash or stop +processing all requests. + +#### Reliability > Longevity +The system should continue to operate as long as it is needed. It +should not gradually use up a limited resource. Example longevity +defects include memory leaks or filling the disk with log files. + +#### Efficiency +The system's operations should execute quickly, with reasonable use +of machine and network resources. E.g., if one user does one +operation, it should execute efficiently. + +#### Scalability +Scalability is a general quality that holds when the system +continues to satisfy its requirements when various usage parameters +are increased. E.g., a file server might be scalable to a high +number of users, or to very large files or very high capacity disks. +Several specific scalability goals are listed below. + +#### Scalability > Performance under load +This is a specific type of scalability goal dealing with the +performance of the system at times when it is servicing many +requests from many users. + +#### Scalability > Large data volume +This is a specific type of scalability goal dealing with the ability +for the system to handle large data sets. Operations should continue +to be correct and efficient as data set size increases. Furthermore, +the user interface should still be usable as the data presented to +users increases in length. + +#### Operability +The long-term needs of system administrators should be +reliably supported. E.g., is the system easy to install? Can the +administrator recover from a crash? Is there sufficient log output +to diagnose problems in the field? Can the system's data be backed +up without downtime? Can the system be upgraded practically? + +#### Maintainability > Understandability +Will it be easy for (future) developers to understand how the system +works? + +#### Maintainability > Evolvability +Can the system easily be modified and extended over time? + +#### Maintainability > Testability +Can the system easily be tested? Do the requirements precisely +specify possible inputs and the desired results? Can the system be +tested in parts? When failures are observed, can they be traced back +to defects in specific components (i.e., debugging)? Is testing +practical with the available testing tools? + +### Additional Standard Terms + +For additional standard terms, see the following reference sites: + +- [Dictionary.com](http://www.dictionary.com/) +- [Whatis.com](http://www.whatis.com/) +- [NIST Dictionary of Algorithms and Data Structures](http://www.nist.gov/dads/) +- [Free on-line dictionary of computing](http:/http://foldoc.doc.ic.ac.uk/foldoc/index.html) +- [IBM's glossary of computing terms](http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm) +- [Jargon File](http://www.jargon.org/) diff --git a/Use-Cases.md b/Use-Cases.md new file mode 100644 index 0000000..c39296e --- /dev/null +++ b/Use-Cases.md @@ -0,0 +1,1232 @@ + + + + + + ReadySet Markdown + + + + + + Overview + Project Plan + Workflows + Current + + + + +<!-- Markdown content here --> + +# [SRS](SRS) > [Use Case Suite](Use-Case-Suite) > Use Cases +--- + +##### Project: +::PROJECTNAME + +##### Internal Release Number: +::X.Y.Z + +##### Related Documents: +- [Project proposal](Proposal) > [User needs](User-Needs), [SRS](SRS) > [Feature set](Feature-Set) +- [Use case format](use-case-format) +- ::LINK TO USE CASE DIAGRAM +- ::LINKS TO RELEVANT STANDARDS +- ::LINKS TO OTHER DOCUMENTS +--- + +*TODO: Note any aspects that are common to all use cases here. This helps +keep the use cases themselves short. If any use case is an exception, +note it's specific value to replace or add to the default.* + +### Default Aspects of All Use Cases + +**Direct Actors:** + +- ::User: end-user in any role +- ::System: The system being built +- ::When actors are not listed, assume User is doing it. +- ::Items beginning with "see" indicate that System has presented a new screen. + +**Stakeholders:** + +::Project Owners and other members + +**Prereq:** + +::User is logged in + +*TODO: For each use case listed in the [use case +suite](Use-Case-Suite), create an HTML anchor and heading with it's +unique ID, then fill in the rows of the table to specify the use case in +detail.* + +*TIP: It is OK to simply list the names of a lot of use cases without +actually writing the use case in detail. Document the most important use +cases first and come back to less important ones later.* + +*TIP: See detailed tips in the [guidelines for writing usecases](use-case-format.html#guidelines).* + +--- +### UC-00: Configure the site + +**Summary:** + +::The administrator navigates to the site configuration page and uses it to change the behavior of the web application. Specifically, the user-visible timezone is being set. + +**Priority:** + +::Essential + +**Use Frequency:** + +::Rarely + +**Direct Actors:** + +::Admin: Web-site administrator + +**Main Success Scenario:** + +1. ::visit SiteConfiguration page +2. ::see site configuration options +3. ::enter timezone abbreviation for date displays +4. ::submit form +5. ::confirm changes +6. ::see SiteConfiguration page again, with updated values + + +**Alternative Scenario Extensions:** + +- ::If the timezone abbreviation is incorrect, an error message will be displayed and no changes will be made. + +**Notes and Questions** + +- ::How will administrators know the right timezone abbreviation? + - They would know it if they live in that timezone. Maybe we could + provide a drop-down list of all choices, but each would need some explanation. + +--- +### UC-01: Register as a new user + +**Summary:** + +::Users need to register themselves in this web application. + +**Priority:** + +::Essential + +**Use Frequency:** + +::Once per user + +**Main Success Scenario:** + +1. ::visit Login page +2. ::click to register as new user +3. ::enter identifying information: username, email, real name, password (twice) +4. ::submit form +5. ::check email +6. ::reply to confirmation message +7. ::log in + +**Alternative Scenario Extensions:** + +- ::If the username is taken, then the system will suggest an available username based on the user's email address and/or real name. + +**Notes and Questions** + +- ::NOTE +- ::QUESTION + +--- +### UC-02: Request new password + +**Summary:** + +::If a user forgets their password, they can request a new one be emailed to them. + +**Priority:** + +::Expected + +**Use Frequency:** + +::Rarely + +**Main Success Scenario:** + +- ::TODO + +**Notes and Questions** + +- ::Alternatively, we could use password hints. + +--- +### UC-03: Edit user profile + +** Summary:** + +::Users can edit their own account preferences. + +**Priority:** + +::Expected + +**Use Frequency:** + +::Rarely + +**Main Success Scenario:** + +- ::TODO + +--- +### UC-04: View user profile + +**Summary:** + +:: Users can view the profiles of other users under certain circumstances. + +**Priority:** + +::Expected + +**Use Frequency:** + +::Rarely + +**Direct Actors:** + +::Admin: Web-site administrator + +**Main Success Scenario:** + +- ::TODO + +--- +### UC-10: Create course + +**Summary:** + +::An administrator creates dozens of course offerings before the beginning of each school term. + +**Priority:** + +::Essential + +**Use Frequency:** + +::Often + +**Direct Actors:** + +::Admin: Web-site adminisator + +**Main Success Scenario:** + +- ::visit administrative function menu +- ::click add course +- ::enter course information: name, number, instructor, capacity +- ::submit form +- ::see course list with new course added + +--- +### UC-11: View catalog description + +**Summary:** + +::Students may view the course catalog description of a course before registering. They are especially likely to view it if they are prevented from enrolling in a course because of a missing prerequisite. + +**Priority:** + +::Essential + +**Use Frequency:** + +::Sometimes + +**Main Success Scenario:** + +- ::visit one of several in application pages that deal with courses +- ::click link to course description +- ::see course description in pop-up window +- ::close pop-up window to continue using application + + + +**Notes and Questions** + +- ::How do we accommodate users that configure their browsers to block pop-ups? + +--- +### UC-20: Enroll in course + +**Summary:** + +::Students will enroll in courses + +**Priority:** + +::Essential + +**Use Frequency:** + +::Often + +**Main Success Scenario:** + +- ::visit main menu +- ::click link to enroll in courses +- ::enter major and course number +- ::select course section from list of available sections +- ::submit choice +- ::confirm choice +- ::see list of current enrolled courses + +**Alternative Scenario Extensions:** + +- ::If a course is full, then the student may join the wait-list. + - ::Course capacity and number of students currently waiting should be shown so that students may choose the section that they are most likely to be able to get into. + +--- +### UC-21: Drop a course + +**Summary:** + +::A student may drop a course that they are enrolled in. + +**Priority:** + +::Essential + +**Use Frequency:** + +::Sometimes + +**Main Success Scenario:** + +- ::visit list of currently enrolled courses +- ::select course from list +- ::click button to drop course +- ::see warning that they may not be able to add this course again +- ::confirm choice +- ::see revised list of currently enrolled courses + +**Notes and Questions** + +- ::Only one course can be dropped at a time. There is no need to allow students to quickly drop more than one course. +- ::It would be nice to offer an atomic "switch sections" operation that drops and adds another, or does nothing. + +--- +### UC-30: View room description + +**Summary:** + +::Users can view descriptions of classrooms. E.g., is it a lecture hall or a lab? E.g., does it have a built-in LCD projector? + +**Priority:** + +::Optional + +**Use Frequency:** + +::Rarely + +**Main Success Scenario:** + +- ::TODO + +--- +### UC-31: Assign course to room + +**Summary:** + +::An administrator assigns each course to a room. This is often done after a course is created, but it can be redone at any time. + +**Priority:** + +::Essential + +**Use Frequency:** + +::Often + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +--- +### UC-40: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-41: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-42: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-50: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-51: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-52: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-60: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-61: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-62: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-70: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-71: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-72: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-80: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-81: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-82: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-90: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +--- +### UC-91: USE CASE NAME + +**Summary:** + +::1-3 SENTENCES + +**Priority:** + +::Essential | Expected | Desired | Optional + +**Use Frequency:** + +::Always | Often | Sometimes | Rarely | Once + +**Direct Actors:** + +::ACTOR1, ACTOR2, ACTOR3 + +**Stakeholders:** + +::STAKEHOLDER, STAKEHOLDER, STAKEHOLDER + +**Prereq:** + +- ::PRECONDITION +- ::PRECONDITION +- ::PRECONDITION + +**Main Success Scenario:** + +- ::STEP +- ::STEP +- ::STEP + +**Alternative Scenario Extensions:** + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +- ::If CONDITION, then ALTERNATIVE STEPS. + - ::NOTES or DETAILS. + +**Notes and Questions** + +- ::NOTE +- ::NOTE +- ::QUESTION +- ::QUESTION + +<!-- End Markdown content --> + + +
+
+ + + + + + + + + + + + +