ACIDMTM Program ProductSoftware Requirements

Specification

Version 0.03Feb. 25, 2020

Standard Version Number: 3.5Standard Version Date: March 10, 2018

Version HistoryVersion Date Authors Comment

0.01 2/4/2020 Celia Celia’s edits from 1st client meeting

0.02 2/6/2020 Combined version Class edits from 1st client meeting

0.03 2/25/2020 Combined version Class edits from 2nd client meeting

Template Version HistoryVersion Date Authors Comment3.0 7/21/2012 Frank Ackerman Initiating standards versions

3.1 8/2/2012 Frank Ackerman Some non-functional requirements definitions .Added adaptability, enhanceability, and portability

3.2 1/17/2013 Frank Ackerman Added usability comment

3.3 3/6/2013 Frank Ackerman Added a bit more explanatory text and final section 8.

3.5 3/10/2018 Celia Schahczenski Changed format of dates, rearranged, renamed items, removed Illustrative Use Cases, increased some explanations, added appendices including data and report sections.

Montana Tech Software Engineering Students:

These Montana Tech Method software engineering standards encapsulate Dr. Ackerman’s decades of experience in the software industry, the IEEE software engineering standards, and many suggestions from various texts. They have gone through many revisions and additions over the last several years. They are part of your software engineering studies so that (1) you may have the experience of developing software to a standard (which you may find you need to do if you take a job that requires high reliability software), and so that (2) you will have the experience of developing high quality software. You are also invited to participate in the continuing evolution of these standards by studying them critically and making suggestions for their improvement and correction.

document.docx . page 2 of 19

TABLE CONTENTSINTRODUCTION.............................................................................................................5

1.1 SOFTWARE PURPOSE AND SCOPE.........................................................................51.2 DOCUMENT PURPOSE AND CONTENTS.................................................................51.3 REFERENCES.........................................................................................................6

2 GENERAL FACTORS.............................................................................................6

2.1 PRODUCT PERSPECTIVE........................................................................................62.2 PRODUCT FUNCTIONS...........................................................................................62.3 ENVIRONMENTAL CONDITIONS............................................................................72.4 USER CHARACTERISTIC........................................................................................8

2.4.1 User Classes....................................................................................................82.5 DEPENDENCIES.....................................................................................................92.6 ASSUMPTIONS.......................................................................................................9

3 USE CASES................................................................................................................9

3.1 ACTORS................................................................................................................93.2 USE CASES...........................................................................................................9

3.2.1 Create Student Outcome..................................................................................93.2.2 [ Use Case Name 2]......................................................................................11

4 SPECIFIC REQUIREMENTS...............................................................................11

4.1 FUNCTIONAL REQUIREMENTS............................................................................114.2 QUALITY ATTRIBUTES.......................................................................................12

4.2.1 Availability....................................................................................................124.2.2 Human Factors..............................................................................................124.2.3 Usability........................................................................................................124.2.4 Performance..................................................................................................134.2.5 Security..........................................................................................................134.2.6 Reliability......................................................................................................134.2.7 Maintainability..............................................................................................134.2.8 Enhanceability/Extendibility.........................................................................134.2.9 Portability......................................................................................................134.2.10 V&V Activities...........................................................................................134.2.11 Adaptability...............................................................................................13

4.3 NON-FUNCTIONAL REQUIREMENTS WHICH ARE NOT QUALITY ATTRIBUTES..134.3.1 External Interface Requirements...................................................................134.3.2 Development Environment............................................................................144.3.3 Delivery Environment....................................................................................144.3.4 Design Constraints........................................................................................144.3.5 Database........................................................................................................144.3.6 Deliverable Items, Dates and Conditions......................................................144.3.7 Cost................................................................................................................144.3.8 Standards.......................................................................................................14

5 FUTURE ENHANCEMENTS................................................................................15

document.docx . page 3 of 19

APPENDICES..................................................................................................................16

APPENDIX A: DEFINITIONS, ACRONYMS, AND ABBREVIATIONS...............16

DEFINITIONS...................................................................................................................16ACRONYMS AND ABBREVIATIONS.................................................................................17

APPENDIX B: ANALYSIS MODELS..........................................................................17

APPENDIX C: DATA DICTIONARY..........................................................................17

APPENDIX D: REPORT SPECIFICATION...............................................................18

APPENDIX E: BUSINESS RULES...............................................................................19

APPENDIX F: SAMPLE USER INTERFACE............................................................19

APPENDIX G: ISSUES..................................................................................................19

document.docx . page 4 of 19

IntroductionThis section provides an overview of the ACID software. It includes the business objectives and vision of ACID along with the purpose and contents of this document. In ends with references that the reader may find useful.

1.1 Software Purpose and ScopeThe purpose of the ACID software application is to help faculty in the School of Mines and Engineering perform continuous improvement of programs, particularly with ABET criteria 3.

ACID’s primary goals are to: Produce reports to facilitate continuous improvement of engineering programs and make

it easy for faculty, accreditors and others to see the extent to which ABET criteria 3 is being met.

Save faculty time by allowing faculty and staff to easily and flexibly input, store, and retrieve assessment information.

ACID’s vision is as follows:“For faculty in the School of Mines and Engineering who need to assess student outcomes for ABET, ACID is a software tool that captures, tracks and compiles information related to student outcomes and reports it in a meaningful format for continuous improvement of programs. Unlike the AbOut system that does this but only for the Computer Science and Software Engineering programs, our product does it for everyone.”

It aims to support continuous improvement and the evaluation of ABET criteria 3, student outcomes. Facilitating evaluation of ABET’s other criteria is not a primary focus, not is accreditation for other accrediting agencies, such as Northwest.

1.2 Document Purpose and ContentsThe purpose of writing this Software Requirements Specification (SRS) is to allow future developers to better understand the customer goals and desires when they are implementing ACID. Developers will be able to use the details from this document to implement the features into a final application product. This document can also be used to design tests to ensure the application behaves as intended.

Engineering faculty at Montana Technological University, the eventual users of the software, may also find this document helpful.

This document does not attempt to tell how this software should be implemented except in those cases where the customers want the application to be developed in a particular way. Deciding exactly what a system should do, before deciding how it will do it, reduces development time considerable.

document.docx . page 5 of 19

This SRS was developed by the software engineering (SE) students in the course Requirements and Specification (ESOF 328) during the spring semester of 2020.

1.3 ReferencesABET, Accreditation Board of Engineering and Technology, http://www.abet.org

ABET assessment planning tools, https://www.abet.org/events-and-workshops/assessment-planning-resources/assessment-reading-list/

AbOut software tool of the Computer Science Department at Montana Technological University, https://katie.mtech.edu/classes/esof328/Resources/AbOut_SRS_v3.6.pdf

2 General FactorsThis section provides a high level view of ACID, its major functions, environment, users and dependencies.

2.1 Product PerspectiveThis project may be similar to AbOut, software created by and used in the Computer Science (CS) Department at Montana Tech. However, while the CS Department maps course outcomes to student outcomes, many of the engineering faculty report mapping performance indicators to student outcomes. The intention is to make ACID flexible enough to allow both methods.

2.2 Product FunctionsThe following lists the functions and features ACID may will include.

1. Report generator: One of the core ideas of this product is reports generation. Collecting data is useless if it can’t be viewed and analyzed in a meaningful way. ACID shall be able to produce various reports to help with continuous improvement and meeting ABET criteria 3 assessment. Reports must include sample size data to make the results meaningful. Flexibility is needed to allow different departments to collect data in different ways and at different frequencies. At least one client suggested having a custom report builder where a user could define their own reports. These definitions could be saved and used over and over. While the client said they would like this functionality, they said it was low priority.

document.docx . page 6 of 19

2. Personalized front-end/dashboard: A personalized front-end/dashboard that lists programs and courses for a given semester was suggested to simplify the interface so the user is only shown information (programs, courses, etc.) that is relevant to them. What is relevant can be determined from the login credentials. Possibly a dashboard could list the programs a user has access to, so the user can switch from program to program.

3. Tracking improvements and remediation models: One of the core principles of the product vision statement is continuous improvement. To facilitate this the system will be able to track improvements and record what efforts have been made in the remediation of the weaker aspects of courses. For example, the software will allow annotations connected with a low score, where faculty can record how this was addressed, and later, see the result of that intervention.

4. Simple and Intuitive data input: ACID shall be designed such that using it for ABET accreditation will save faculty members time when compared to doing it by hand. Data annotations and tool tips that tell what belongs in each field and how data calculations will be performed, will be used to simplify data input.

5. Map old ABET criteria to new criteria: Periodically ABET updates their criteria. In many cases they provide mappings between the old and the new criteria. ACID shall be able to store and utilize this data.

6. Historical reports: ACID shall be able to generate reports from previous semesters. When information is changed, those changes must not permeate back to previous reports.

7. Audit trails: ACID shall create audit trails after important edits or modifications to the data, detailing who made the changes and exactly what was changed.

8. Backup Data: ACID shall provide a mechanism in which large backups of the database can be created.

2.3 Environmental ConditionsACID as a product will work alongside a few other existing programs and tools in use by the School of Mines and Engineering. These systems may include Moodle and the Montana Tech Central Authentication Service (CAS). Interfacing with Moodle for getting grades of assignments may be convenient for faculty. The system will also work with CAS so faculty members can use their same credentials they use to login to school email and campus computers. CAS also helps to ensure the security of the system. An environmental map of how ACID will interact is depicted below in Figure 1. In this figure faculty are able to get grade information from Moodle. Faculty are also able to input metric information directly into ACID. ACID also interfaces with CAS to authenticate the users of the system.

document.docx . page 7 of 19

Figure 1 Environmental Map

2.4 User CharacteristicThe primary users of this system are the faculty and staff of the School of Mines and Engineering. An understanding of the assessment process, a familiarity with web browsers, and proficiency completing forms on a computer, is assumed. Between research, teaching, and service, engineering faculty have a lot on their plate and are looking for a quick, easy-to-use system that produces quality reports that adhere to ABET requirements.

2.4.1 User Classes

1. Department ABET Coordinator: This is a faculty member in a department who is tasked with overseeing the continuous improvement and ABET assessment of the program. The person with the role of ABET Coordinator may change over time and multiple people can play this role for each department. 2. Faculty member: This is someone who inputs metric data for the classes they teach into the system.3. Department admin: This person may enter student names into course offerings and other tasks. 4. System Admin: This person has responsibility for maintaining the system after it has gone live. This person(s) will probably have read/write access to all data.5. API: This actor isn’t human. An API (Application Program Interface) allows a system to programmatically access the data in the application and re-use it in the future.6. ABET accreditor: This user class is for the ABET accreditors that visit the school. This user class is optional as it has not yet been determined if it is wanted.

document.docx . page 8 of 19

2.5 DependenciesThe main dependency expected is utilizing Montana Tech’s Central Authentication System, CAS. This enables users to use their existing Montana Tech passwords to access the software and simplifies the development process, as CAS will handle user authentication.

Another dependency being considered is interfacing with Moodle. If the project incorporates functionality that allows grades from Moodle to be automatically added to ACID, the system will have a dependency on Moodle.

2.6 AssumptionsFaculty are being encouraged to use the assessment methodology which the Electrical Engineering Department is using for tracking ABET criteria 3. Thus, one motivation for creating this software is to standardize current methods for tracking ABET criteria 3.

3 Use CasesThe following use cases describe how users will interact with ACID. They outline, from a user’s point of view, ACID’s behavior as it responds to user interactions. Each use case is represented as s sequence of simple steps, beginning with a user’s goal and ending when that goal is fulfilled.

3.1 Actors

Primary Actor Use Cases

Department ABET Coordinator

1. Create Student Outcome

Department Admin1. Create Student Outcome

3.2 Use Cases

3.2.1 Create Student Outcome

Created By: ESOF 328 Class of 2020

Last Updated By: Justin Bak

Date Created: 02/15/2020 Date Last Updated: 02/15/2020Actors: ABET Coordinator, Department Admin

Description: User creates a student outcome for their program

document.docx . page 9 of 19

Preconditions: 1. User is logged in.

2. User wields permission to create a student outcome in the associated program.

Postconditions: 1. Unless the outcome prefix and identifier are duplicated, or the user exits the use case early, the new student outcome has been created and is associated with the program.

Normal Flow: 1.0 Create a student outcome1. User indicates desire to create a student outcome2. A ‘enter student outcome’ interface appears that allows the user to select a prefix, enter a prefix identifier, enter the text of the student outcome and to submit the data3. The user is informed that the student outcome has been created

Alternative Flows: 1.1 User doesn’t submit student outcome and no changes were made (branch during step 2)1. User navigates away from entering the student outcome, or

indicates desire to exit ‘input student outcome’ interface, before any changes were made

2. Use case exits

1.2 User doesn’t submit student outcome after changes were made (branch during step 2)1. User navigates away from entering the student outcome, or

indicates desire to exit ‘input student outcome’ interface, after changes had been made

2. User is warned that they have unsaved changes and asked if they wish to proceed

3. User indicates preference4. If ‘yes’ use case exits; if ‘no’ the user remains (or returns) to step 2

1.3 Duplicate student outcome (branch after step 2)1. The user is informed that a student outcome with the given prefix

and identifier is already in the system. The prefix, identifier and text of the student outcome are displayed, and the user is asked if they want to associate that student outcome with their program.

2. User indicates preference 3. If ‘yes’ the user is informed that the student outcome is now

associated with their program; if ‘no’, user is informed that no changes were made

document.docx . page 10 of 19

Exceptions: 1.0.E.1 Internal error (branch after step 2)1. The system is not able to connect to the database or some other

internal error 2. User is informed that an error occurred, that the developers are

sorry, and the nature of the error

Includes/Extends: nonePriority: Medium (the system can be prepopulated with necessary student

outcomes for each program)Frequency of Use: Frequently when setting up the system, or when ABET changes

outcome. Infrequent at other times.Business Rules: Some outcomes are used by multiple programs

Special Requirements: none

Assumptions: 1. The user is associated with a program. 2. The system automatically associates the created student

outcome with the program the user is associated with. 3. The software won’t allow a user to create a student outcome

when that user doesn’t wield permission to do so.4. The software won’t allow the user to submit student outcome

information unless valid information is entered. 5. Existing outcomes should be updated through an “Update

student outcome” use case.

Notes and Issues:

3.2.2 [ Use Case Name 2]

…

4 Specific Requirements[The Specific Requirements section should contain all the requirements for the subject software. The details within this section should be defined as individual, specific requirements. Each specific requirement should be stated such that its achievement can be objectively verified by observation, inspection, usability testing, functional testing, analysis, or a combination of these. The method verification must be described. Each requirement should be clearly identified for tracking.]

4.1 Functional Requirements[This subsection should specify how the software product will react to every possible input situation. It describes all the actions that must take place in the software in

document.docx . page 11 of 19

response to every input. Pertinent changes in the environment are considered to be inputs.

Care must be taken to avoid dropping into design details. In the user cannot directly experience the effect of a requirement it probably crossed the line into design.

Functional requirements should be logically grouped. Each group should have a short, unique (within the SRS) abbreviation and a number. The word processing section number will probably change as the SRS is developed.

For each identified requirement an optional rationale for that requirement may be given.

Most modern software should provide at least a modicum of user help. For very complex applications in situ help may be supplemented by a user’s manual (or manual page) but for many simple applications comprehensive in situ help is sufficient.]

4.2 Quality Attributes[This subsection specifies criteria used to judge the operation of a system, rather than specific behaviors of the system. Specify the specific behavior of the system in the functional requirements.]

4.2.1 Availability

4.2.2 Human Factors

[Not everyone has the same inherent mental and physical capabilities vis-à-vis a given computer application. For example if sound is part of the application, will other clues be given that will enable a hard of hearing user to use the proposed application as well as person with normal hearing; similarly for color blindness. Define these factors, if necessary, with validation criteria.]

4.2.3 Usability

Users expect ACID to be flexible. Different departments track ABET criteria 3 differently and should be allowed to use whichever method they like in ACID.

For example: Petroleum counts their sample size by metric/scores. That is, if there is a class of

10 students and a class of 15 students, where the students overlap, the count the sample size as 25. Petroleum also collects data twice every six years, which was recommended by the Dean of the School of Engineering to allow for an early indication if an outcome isn’t being met.

Safety, Health & Industrial Hygiene collect data every semester and this is done by individual classes.

document.docx . page 12 of 19

Data could also be collected in cycles, so each year some outcomes are being assessed, but not all. For instance, focus on 2-3 outcomes each year, so that in the course of years, all 7 outcomes are assessed twice.

4.2.4 Performance

4.2.5 Security

4.2.6 Reliability

[Reliability is specified as mean-time-to failure of an operational item. An operational profile must be specified.]

4.2.7 Maintainability

4.2.8 Enhanceability/Extendibility

[If the future it might be necessary to change the Functional requirements in specified ways, what is the maximum estimated effort required to make such changes and what is the rationale for this estimate?]

4.2.9 Portability

[If in the future it might be necessary to change the above Development or Delivery Environments (DV or DL) to other specified environments, what is the maximum estimated effort required to implement such changes and what is the rationale for this estimate]

4.2.10 V&V Activities

4.2.11 Adaptability

[If it is specified that in the future it might be necessary to change any of the above Non-Functional requirements, what is the maximum estimated effort required to implement such changes and what is the rationale for this estimate.]

4.3 Non-Functional Requirements Which Are Not Quality Attributes[This subsection specifies non-functional criteria such as platform, deployment, interface, design and document requirements. If there is not a document describing project requirements, those requirements (cost, schedule, etc.) can be placed here.]

4.3.1 External Interface Requirements

4.3.1.1 Hardware

4.3.1.2 Software

4.3.1.3 Communications

document.docx . page 13 of 19

4.3.2 Development Environment

4.3.3 Delivery Environment

4.3.3.1 Site

[This subsection should specify any requirements for installation or operation of the software that might change the pre-existing configuration of the user site.]

4.3.3.2 Operations

[This subsection should specify normal and special operations required by the user to include: Various modes of operation within the user organization Periods of interactive operations and unattended operations Data processing support functions Backup and recovery operation.]

4.3.4 Design Constraints

[Sometimes a client will require certain design constraints, for example the use of a certain system configuration or the use of particular algorithm. Such constraints are described in this subsection.]

4.3.5 Database

[This optional subsection specifies requirements for any database to be developed as part of the product. The information in this section may include:

Types of information to be stored Table attributes (queried, supporting, updated) Frequency of access Accessing capabilities and requirements Data elements and file descriptors Retention requirements for data.]

Take care to avoid design details. Unless so requested by the client, this section should only contain as much information about saved data as is necessary to fully document any of the requirements given above.]

4.3.6 Deliverable Items, Dates and Conditions

4.3.7 Cost

4.3.8 Standards

document.docx . page 14 of 19

5 Future Enhancements This software may eventually be enhanced to support non-engineering departments at Montana Tech, Northwestern accreditation and facilitating assessment of ABET criteria, other than criteria 3.

document.docx . page 15 of 19

Appendices[In some cases, it is helpful to move items out of the main portion of the Software Requirements and Specification Document. These items can appear here. Alternatively, move these items into the main part of the document.]

Appendix A: Definitions, Acronyms, and Abbreviations

This appendix provides definitions for terms used in this document or in the software.

DefinitionsABET Coordinator Person in a department tasked with overseeing continuous

improvement and ABET accreditation for the department.

Assessment One or more processes that identify, collect, and prepare data to evaluate the attainment of student outcomes. Effective assessment uses relevant direct, indirect, quantitative and qualitative measures as appropriate to the outcome being measured. Appropriate sampling methods may be used as part of an assessment process.

Metric Items used to determine if students have met student outcomes, these are typically mapped to PIs.

Moodle A web application where instructors can post student grades on assignments and exams. Moodle is currently used by all departments in the School of Mines and Engineering.

Program indicator (PI)

Concrete, measurable statement of action the student should be able to perform to demonstrate attainment of student outcomes.

Typically, 2-3 PIs per outcome and 3-4 “measures” per PI. It was speculated that AbOut “assessments” are what clients call “measures”. Thus, whereas AbOut maps outcomes to measures (via courses and offerings of courses), clients map outcomes to PIs to measures.

PIs differ from one department to the next, but are standardized within a department

Student outcome Describes what students are expected to know and be able to do by the time of graduation. These relate to the skills, knowledge and behaviors that students acquire as they progress through the program.

document.docx . page 16 of 19

Acronyms and AbbreviationsAbOut ABET Outcomes – a software system developed and used by the CS

departmentABET Accreditation Board of Engineering and TechnologyACID Assessment and Continuous Improvement DatabaseCAC Computing Accreditation CommissionCAS Central Authentication ServiceCO Course OutcomeCS Computer ScienceEAC Engineering Accreditation CommissionEE Electrical EngineeringPI Performance IndicatorSO Student OutcomeSRS Software Requirements SpecificationSW Software

Appendix B: Analysis Models[Optionally, include any pertinent analysis models, such as activity diagrams, state-transition diagrams, entity-relationship diagrams, or a formal specification.]

Appendix C: Data Dictionary[The data dictionary defines the composition of data structures and the meaning, data type, length, format, and allowed values for the data elements that make up those structures. In many cases, storing the data dictionary as a separate artifact, rather than embedding it in an SRS is beneficial. This also increases its reusability potential in other projects.

List data items alphabetically. Make each name a bookmark so each time the name occurs in this SRS it can be link to this entry via a hyperlink. Choose names with care. The expectation is that these names will persist in the design and implementation.]

document.docx . page 17 of 19

Data Element

Description Composition or Data type

Length Values

Name of data item being defined

Textual description of the business meaning of the data element

For primitive data elements: data type (integer, floating point, alphabetic, date, etc.) and, as appropriate, format (e.g. date as MM/DD/YYYY).

For data structures show the components that comprise the structure. ,

Maximum number of characters for primitives; blank for structures

List of allowed values, default, rules governing legal values, and any other description of the data values

… … .. … …

Appendix D: Report Specification[This optional appendix contains descriptions of reports that the system needs to generate. Many applications involve generating reports from one or more databases, files or other information sources. Exploring the content and format of the reports needed is an important aspect of requirements develop. Describe the contents and layouts of each report, including changes being made in an existing version of the report. Indicate the conditions that will trigger generating the report (e.g., manual or automatic) the timing of report generation, and the disposition of the report, such as to whom it is sent or where it is stored.

Use the following template to document business rules.

Report ID:Report Title:

Report Purpose:Data Sources:

Frequency and Disposition:Latency:

Visual Layout:Header and Footer:

Report Body:End-of-Report Indicator:

Interactivity:Security Access Restrictions:

document.docx . page 18 of 19

If appropriate, provide a mock-up or a sample of the report, or an illustration of a similar existing report, showing the desired layout. ]

Appendix E: Business Rules[This optional appendix describes business rules that are relevant to the proposed system. Use the following template to document business rules.

ID Rule Definition Type of Rule Static or Dynamic

Source

BR-1 Definition 1 Fact, constraint, computation

Static or dynamic

Name, role or document

… … .. … …]

Appendix F: Sample User Interface [If a sample user interface exists, place it here. Make it clear that this user interface is only an example. If something is required in the user interface, state that earlier in this document.]

Appendix G: Issues [This optional appendix is a dynamic list of the open requirements issues that remain to be resolved, including TBDs, pending.]

Outstanding issue – Some clients use rubrics, rather than scores, and use summary data, rather than student data. At least one of the clients was worried about tracking data by specific users.

document.docx . page 19 of 19