Course Project#1: Agile software development with UML (Unified Modeling Language)
1) I NEED HELP IN CREATING A SOFTWARE REQUIREMENTS (SRS) DOCUMENT, HERE'S THE BUSINESS SOLUTION TO SOLVE:
1. A CASE EXAMPLE: creating an information system such as automating an outdoor goods rental company's retail system, that takes their manual system, and automates it.
a. Allowing the customer (ACTOR) to access their inventory database (currently available), online within a webpage hosted on a web server
b. Allow customers to login into the website, using a customer ID and password, and authenticate/validate the user with the company's existing customer account information on their server
c. Allow customers to search for available rental inventory
d. Allow the customer within the website to purchase the rental, validate the purchase, and produce a receipt, and notify the company's ACCOUNTING department (ACTOR)
e. Allow customers to create a customer profile/account
f. Email the customer, the rental purchased receipt
g. Produce a cash received report for the ACCOUNTING department (ACTOR)
h. Produce a management report for MANAGEMENT (ACTOR)
i. The website would be designed to support the interface to MS Internet Explorer
j. Here would be software system's ACTORS/ENTITIES that would interact with the designed software:
iv. WEB ADMINISTRATOR
v. DATABASE SYSTEM
vi. ACCOUNTING SYSTEM
2. Please if you have any other suggestions, or other software solutions/implementations for a business need that you have previously developed or have experience with, that could be the utilized case for this project as well.
3. Just a note, the format that you produce doesn't have to be in a finished state, I'm more concerned about the developed concepts. It sounds like a lot, but it's really more about describing the system's conceptual processes and descriptions.
4. I also have attached various supporting documents from my course to assist you with the different topics I list below. And I can send additional examples of each of the phases I've described below, you can contact me at rodl0512 at gmail . com
2) Then assistance with creating the software concept:
SOFTWARE/SYSTEM REQUIREMENTS SPECIFICATION (SRS) DOCUMENT
1. FUNCTIONAL DECOMPOSITION DOCUMENT
2. DESCRIPTION OF THE FUNCTIONAL ELEMENTS
3. CONTEXT DATA FLOW DIAGRAM (DESCRIBING THE SOFTWARE PROCESS MODELS INTERACTIONS)
a. Level 0
b. Level 1
c. Level 2
d. Level 3
4. REQUIREMENTS MATRIX. (TAKING EACH FUNCTIONAL DECOMPOSITION DOCUMENT ELEMENT AND LISTING ITS ROLL WITHIN THE MATRIX)
5. USAGE SCENARIO (A USAGE SCENARIO FOR THE DESIGNED SOFTWARE, ORGANIZED INTO USE-CASES)
a. User profiles (profiles of all user categories described)
b. Use-Cases (all the use-cases for the software)
c. Business Process Model
d. Work Flow Chart
e. Special requirements associated with the use of the software
6. DATA MODEL AND DESCRIPTION
a. Description of the Data Objects that are managed by the software
b. Data Objects and their major attributes described
c. Data Objects relationships
? Relationships between the data objects in ERD form (no detailed information is needed here)
d. Complete Data Model (in ERD form for the main software)
e. Data dictionary (to maintained in electronic form)
7. FUNCTIONAL MODEL AND DESCRIPTION (A DESCRIPTION OF THE EACH MAJOR SOFTWARE FUNCTIONAL, ALONG WITH DATA FLOW OR CLASS HIERARCHY (OBJECT ORIENTED)
a. Description of each software function in Function n format
i. Processing narrative (PSPEC) for function n. (Processing narrative for function n here)
ii. Function n flow diagram. (A diagram showing the flow of info through the function and the transformation it undergoes)
iii. Function n interface description. (Detailed description of the input and output interfaces for the function is presented.
iv. Function n transforms. (Detailed description for each transform (sub functions) for functions n.)
b. If required, then the same above items for the transform k descriptions
i. Transform k description
ii. Transform k interface description
iii. Transform k lower level flow diagrams
iv. Transform k interface description
c. System performance issues. (Special performance required for the subsystem specified)
d. Software Design Constraints (Any design constraints that will impact the subsystem noted)
8. SOFTWARE INTERFACE DESCRIPTION (SOFTWARE INTERFACE TO THE OUTSIDE WORLD DESCRIBED)
a. External machine interface
? Interfaces to other machines(computer or devices) described
b. External system interfaces
? Interfaces to other systems, products or networks described
c. Human interface
? Overview of any human interfaces to be designed for the software is presented
d. Control flow description
? control flow for the system is presented
9. BEHAVIORAL MODEL AND DESCRIPTION (A DESCRIPTION OF THE BEHAVIOR OF THE SOFTWARE DESCRIBED)
a. Description for software behavior (detailed description of major events described)
b. Events (Listing of events (control, items) that will cause behavioral change within the software system developed)
c. States (listing of states (modes of behavior) that will result as a consequence of events described)
d. State Transition Diagram (depicting the overall behavior of the system)
e. Control Specification (CSPEC). (Depicting the manner in which control is managed by the software)
10. RESTRICTION, LIMITATIONS AND CONSTRAINTS. (SPECIAL ISSUES WHICH IMPACT THE SPECIFICATION, DESIGN OR IMPLEMENTATION OF THE SOFTWARE DESCRIBED)
11. VALIDATION CRITERIA (DESCRIBING THE SOFTWARE VALIDATION PROCESS OR APPROACH)
a. Classes of tests. (types of tests to be conducted specified, focused on black-box testing to be described)
b. Expected software response (expected results from testing described)
c. Performance bounds. (special performance requirements are described)
12. SYSTEM TRACEABILITY MATRIX INFORMATION. (DESCRIPTION OF STATED SOFTWARE REQUIREMENTS BACK TO THE SYSTEM SPECIFICATION)© BrainMass Inc. brainmass.com March 4, 2021, 9:35 pm ad1c9bdddf
Please find the solution in the attached file.
Please do let me know, if you have any query. I would be happy to assist you further with this posting.
SOFTWARE REQUIREMENTS SPECIFICATION
This document provides the requirement specifications for an online registration system of a University. The online registration system will be used for the enrollment of students into various terms and the courses offered by the University in that term. The Professors will also get information about the courses they are assigned for the term. The assignments will also also be published and submitted online. This document describes all data, functional and behavioral requirements for software.
1.1 Goals and objectives
To provide a simple information system that automates the registration of students in various courses offered by the university. To maintain a central database for all students, professors, courses, administrator and accounting system.
1.2 Statement of scope
The system would take the details of the enrolling students as input. The system would assign the courses to students, based on various priorities given to certain students. The system would also assign courses to professors based on their qualifications and fields of interest. Class rosters for each classroom would be published. An academic calendar giving details for the entire year would also be available.
1.3 Software context
The software would be custom developed software, based on the needs of the University. The software will be built on an evolutionary basis. The cost of software licenses and the hardware required for the system would be borne by the University. The source code would be provided to the University for Furthur Development.
1.4 Major constraints
The software will be built for 64-Bit Operating systems, and will not work for 32-bits system or below. For the system to work properly, the University must have a fast network with a speed of at least 2 Mbps.
2.0 Usage scenario
This section provides a usage scenario for the software. It organized information collected during requirements elicitation into use-cases.
2.1 User profiles
Administrator: - The administrator has the responsibility to maintain the system security and regular updating. He must be well versed with the concepts of the database and network administration.
Student/Professor: - A student/professor is a user who must be able to handle the system for his use after reading the help file. He will be presented only with the abstract details. Technically, a student must simply know web browsing and some knowledge about the procedures of the University.
Registrar :- The registrar retrieves the registration report, and confirms it. He must be technically sound with the use of MS- Office tools.
The student registers for the courses in the system, the courses are allotted to the professors who teach that particular course and administrator generates the reports, while the Registrar confirms it.
2.3 Special usage considerations
A separate help file will be prepared for the Administrator, Students, Professors and the Registrar, where detailed information about the system would be provided.
3.0 Data Model and Description
3.1 Data Description
This system is meant to be used by students, professors, administrators, and registrar. Courses will link the students and the professors. Administrators will oversee the enrollment process, while the Registrar will confirm it.
3.1.1 Data objects
The system will have the following data objects.
• Students - ...
The software requirements with Agile UML OOD methodology is examined.