Software Requirements Specification (SRS) Car Finish Inspection. Team: 6 Adam Schoonmaker, Caleb Swanson, Cory Madaj, Zhiming Jiang

Transcription

1 Software Requirements Specification (SRS) Car Finish Inspection Team: 6 Authors: Customer: Instructor: Adam Schoonmaker, Caleb Swanson, Cory Madaj, Zhiming Jiang General Motors Dr. Marilyn Wulfekuhler

2 1 Introduction The purpose of this document is to give a thorough description of the Car Finish Inspection system. This will explain the functionality of the system along with various constraints and requirements of the system. It will define necessary vocabulary to be able to utilize the system and the interfaces of the systems. It is meant to explain what the system will do and be utilized by both the users and developers of the system. 1.1 Purpose The purpose of this SRS document is to show those interested in this system how it s going to be implemented and speed up/make digital documentation of car inspection. This includes the function and specification of the Car Finish Inspection system. The intended audience for this system is the factory analysts and managers along with the system developers who have created the product. 1.2 Scope Software to be produced is an ipad app that will allow the user, General Motors, to record and log data from their car inspections simply and easily in a few taps. Specifically, this logged data will involve flaws and defects that individual cars contain from various phases within the painting process. The data will then be able to be transferred to a local computer in CSV format where it can then be generated into various reports. This step is separate from inputting data as it will require an internet connection that is not necessarily readily available at all times. This digital information is easier to parse, process, deliver, and retrieve. It will include inspector identification, graphical display of where defects are located, and specification of type of defect and the model it is on. The information will be delivered to management who need it. The goal of the Car Finish Inspection system is to provide a unified system in a digital world to track and maintain the list of defects within cars. Moving from a paper Page 1

3 system to a computer based one will allow for easier tracking, maintaining, viewing, finding, and implementing changes for the different finish phases within a car s life. 1.3 Definitions, acronyms, and abbreviations Term GM DPU E coat Polish deck / Top coat Primer CSV SRS UML Definition General Motors Defects per unit Process of using electricity to apply paint or lacquer; first stage of the paint process Last stage of paint process to add shine and seal off inner layers Second stage of paint process ensuring better adhesion Comma separated values file that easily stores information for a database. Software requirements specification file. Unified Modeling Language Page 2

4 1.4 Organization This SRS contains information about the Car Finish Inspection system, like the customer and the process of what is in it. Sections two through eight heavily involve the system, regarding how it is setup, created, utilized, and described. These sections also touch on the constraints and assumptions of the software in order to provide a more unified explanation for both the user and the developers. Section 9 involves requirements that were gained from General Motors and are setup in a hierarchical fashion for easy readability. Furthermore, section 10 contains various diagrams describing how the system is setup with explanations for all. Section 11 through 13 involve the prototype of our Car Finish Inspection System. They seek to explain how the prototype for our system shows functionality wise, what is needed to run that prototype, and a sample scenario of using it. Sections 14 through 15 contain ending information containing references and a point of contact for further regard to both this document and the system we are developing. Page 3

5 2 Overall Description These sections following will heavily involve the explanation and details of the Car Finish Inspection system. Included information will include the requirements, setup, decisions, specifications, constraints, and other viable details about the system. This will help to provide a unified explanation to be read and used by the users and developers of this system. Page 4

6 3 Product Perspective The Car Finish Inspection system is a two part system developed for General Motors. It is to be used to track defects on vehicles and create a system where quality can both be tracked and changed through implementations. This system was developed to be utilized in not one, but numerous locations, in a quick and efficient manner. The first step of the system is to mark and explain various defects that are on a set of vehicles. This happens at three different stages within the painting process. This step involves our system as an ipad program at the moment. The user will input what is needed and then save the information. Later, the user will deliver this information to the central computer utilizing functionality built into the system. At this step, an internet connection is required to transfer over the data, but since this can be done at anytime, a user is not required to have a connection while inputting data. This central computer can then be utilized to create and maintain reports on the defects to help visualize the data and provide easy means to look at changes to lower the defects. Data Flow Diagram: explains the flow of data that will occur within the Car Finish Inspection System. Page 5

7 Page 6

8 4 Product Functions The Car Finish Inspection system allows analysts in the factories to document defects seen on cars on a tablet device, will identify the inspector inputting it, and give the data easily to the management so that they can analyze and look up the data in a more simplified manner. The user will be able to input defects based on location, type, and severity onto a car model. This will be a quick process as the vehicles are on the move while implementing this, so creating a system with simplicity and effectiveness was a top priority. After the user is finished, he can then save the information locally to the tablet. At a certain point, as long as an internet connection is acquired, the user can then export the data from the tablet to the central computer. Once there, the manager or other user can then generate various reports to visualize the data in a clear cut fashion. The main goals of this system is to eliminate the need for paper implementations and to automate the report generations from the generated data. Being able to complete these objectives will help to created a system that is easily accessible and maintainable for the foreseeable future. Creating a more unified setup like this helps to eliminate problems that arise from the storage and implementation of defects for the various vehicles. This will help to improve efficiency and save time for all involved. Page 7

9 5 User Characteristics User is doubtlessly going to be the inspectors of the cars and the supervisors who review the analysis documents. They are assumed to have the necessary skill level and expertise the factory that employs them expects of them. This includes any needed abbreviation knowledge that is not explained, vehicle information, knowledge of defects, and also how to utilize an ipad and personal computer. Page 8

10 6 Constraints The Car Finish Inspection system runs on an Apple ipad running ios version 9.0 or higher. The system needs an internet connection to transfer data from the ipad to a central computer. This is not required however, during time of inputting the data into the ipad. A central computer that is able to read and open csv files is needed to generate reports and to view and utilize the data. Systems such as Windows 7 or the newest versions of Apple s OS X are recommended. It is acknowledged disc space is sufficient enough to hold essentially unlimited records. The records will be in csv format, allowing for small storage requirements. However, if the central computer gets near full, it is advised to put older information onto a backup drive for storage. There is only one transfer from an ipad to the central computer that can happen at a time. This is to prevent corrupted transfers to the computer. Page 9

11 7 Assumptions and Dependencies In order to run the Car Finish Inspection system, there are a couple of assumptions. The first is that the plants using the software will have at least one Apple ipad running on ios 9.0 or higher. Along with this, a central computer is assumed to be available to save the data that comes from the ipad. A wireless internet connection should be available someone within the plant to transfer the data over from the ipad to the computer; both the ipad and the computer need this connection, hence the wireless requirement. The user will interact with the ipad inputting defects on different units as required. This should happen out on the floor on the plant where the user can view and document the defects of the car. Once the user is finished with the units, they will save the data and have the option to push it to the computer at a later time. This way an internet connection will not be required at all times. The manager or other users can then access this information on the computer and generate reports as needed. While generating reports, a user should not be transferring data from the ipad to the central computer. Page 10

12 8 Apportioning of Requirements The current scope of the Car Finish Inspection system contains all of the requirements that have been documented and received. Further changes that could add more functionality to the system, but are not required are listed here. Have an option to choose and keep track of the color of the unit. Since the color of a unit has little effect on the system as a whole, this might not be very cost effective to implement. Have an optional comments section to enter for each unit in case the need is there to comment on something. New things arise all the time, so having this comment sections might be nice to document things that were not thought of at the time. However, speed in documentation is important, so having a section like this might take to long. Implement the system on Android tablets for more globalization. Choosing to use ipads is a little more costly decision, but the universality and dependability of ipads are a lot higher than Androids currently. Page 11

13 9 Specific Requirements 1. Three checkpoints need to be implemented 1.1. LPO/Elbow/E Coat checkpoint 1.2. Primer checkpoint 1.3. Finesse/Top coat/polish deck checkpoint 2. Generate report on defects per unit 2.1. Generate daily Can have more than one report at same checkpoint for one day 2.2. Generate for all three checkpoints 2.3. Show the audit details Start time, end time, shift, num of units, total defects, defects per unit, date, analyst, checkpoint 2.4. All defects from all cars plotted on one wireframe model Have different colors for different defects Have a legend for the colors 2.5. Have tables for each part of the unit List the number of defects by severity and the total defects 2.6. Identify the plant on report 2.7. Print the report 2.8. Save the report indefinitely 3. Generate defects per surface 3.1. Generate on demand for selectable date range 3.2. Generate for all three checkpoints 3.3. Identify the plant on report Page 12

14 3.4. Print the report 3.5. Save the report indefinitely 4. Generate a trend of defects per unit over time 4.1. Generate on demand for selectable date range 4.2. Generate for all three checkpoints 4.3. Split into weeks Have the shift for each week Have the Initials of the analyst for each week Have the defects per unit for each week 4.4. Create a line graph of defects per unit by week 4.5. Identify the plant on report 4.6. Print the report 4.7. Save the report indefinitely 5. Need all data in a csv dump 6. If error is made after the report is generated, don t present the report 7. Analyst must access system 7.1. Record time and date when analyst starts session Allow to be modified in case of transfer from paper report 7.2. Analyst enters the shift (3 possible shifts) 7.3. Analyst inputs name 7.4. Analyst chooses the current checkpoint 7.5. Analyst can enter a defect on unit Choose the unit (type of car) Page 13

15 that plant on being made filled out Can only choose cars currently being produced at New car diagrams need to be able to be added later Don t remove old car diagrams that are no longer Each unit must have a left side, right side, and top Unit can only be one model, not parts of many Choose the severity from three different levels Choose the location of the defect on the wireframe model Choose the type of the defect from list Have other defect type so they can change later Add new type of defect if needed 7.6. Need at least 10 sampled units to save data, otherwise there is no report that day 7.7. Record time when analyst finishes audit Allow to be modified in case of transfer from paper report 7.8. Analyst can edit data until the report is generated 7.9. Need to save data locally until an internet connection is established Then it can be transferred over into csv dump 8. Unauthorized users should not be allowed to see the data 9. Have a user manual to teach how to use the system (Extra Credit) Page 14

16 10 Modeling Requirements Use Case Diagram: shows the different use cases of the system in which the various users, managers, analysts of the system are able to do. The use case diagram above is helpful as an overview of the system. It helps to show to all involved in the system how it will be utilized. Below each individual part of the use case diagram is documented and explained more than the diagram does. Use Case Name: Actors: Description: Type: Includes: Extends: Modify System Developer, Manager Change the system as needed for more requirements/fixes. Code Page 15

17 Cross refs: , Uses cases: Use Case Name: Actors: Description: Type: Includes: Extends: Cross refs: 7 Uses cases: Record Defect Data Analyst Input defect data for a certain checkpoint. This includes info like the Start time, end time, shift, number of units, total defects, date, analyst, and checkpoint. CSV Use Case Name: Actors: Description: Type: Includes: Extends: Cross refs: 7.9 Uses cases: Submit Defect Data Analyst Allows the analyst to submit the data from the ipad and to the computer for storage and report generation. HTTPS POST Use Case Name: Actors: Description: Type: Includes: Produce Checkpoint Report Analyst, Manager Takes the data that has been transferred to the central computer and generates the specified report. CSV/Excel Print Report Page 16

18 Extends: Audit Report, Defects Per Surface Report, Trend of Defects Report Cross refs: 2, 3, 4 Uses cases: Use Case Name: Actors: Description: Type: Includes: Extends: 3 Cross refs: Uses cases: Defects Per Surface Report Analyst, Manager Create a report of defects per surface to be utilized for various purposes. CSV/Excel Produce Checkpoint Report Use Case Name: Actors: Description: Type: Includes: Extends: Cross refs: 2 Uses cases: Audit Report Analyst, Manager Create the audit report for the day showing defects per unit and summarizing information about the defects CSV/Excel Produce Checkpoint Report Use Case Name: Actors: Description: Type: Includes: Trend of Defects Report Analyst, Manager Create the trended defects report showing the defects per unit over a certain time period. CSV/Excel Page 17

19 Extends: Cross refs: 4 Uses cases: Produce Checkpoint Report Use Case Name: Actors: Description: Type: Includes: Extends: Cross refs: 2 Uses cases: Print Report Print out the report to use within the plant. Excel Produce Checkpoint Report UML Diagram: shows the class overview of the system and how they relate to each other. Page 18

20 The UML diagram shows an overview of the parts of the system and how it is setup. It is a useful tool to be able to view how the system is put together and allow for easy viewing on how a new change can be implemented. Class: Function: Relationships: Factory The base overview of the system involving the current factory. Contains numerous models and analyses. Attributes location (text) name (text) the location of the current factory the name of the current factory Class: Function: Relationships: Analysis An analysis of a certain stage of the paint process including defects and other various information Belongs to a factory and has at least 10 samples. Attributes analyst (text) checkpointstring (text) finish (bool) shiftstring (text) start (time) the name of the analyst the current checkpoint being analyzed whether or not the analysis is finished the current shift during the analysis the time of the analysis Class: ModelType Page 19

21 Function: Relationships: To store and utilize various models of the cars for purposes of defect display Belongs to a factory and is used in a sample. Attributes name (text) The name of the model picture. Class: Function: Relationships: Sample A specific sample of a car and the defects associated with it. Contains defects and a model associated with the corresponding car and belongs to a certain analysis. Attributes leftsidedone (bool) rightsidedone (bool) Whether the left side is completed or not. Whether the right side is completed or not. Class: Function: Relationships: Defect Keep information regarding to a certain instance of a defect on the vehicle. Belongs to a specific sample and includes the defect type associated with it. Attributes drawingsideint (number) locationx (number) The side that it is drawn on. The location of the defect on the x axis. Page 20

22 locationy (number) planeint (number) regionint (number) severtityint (number) sideint (number) The location of the defect on the y axis. The plane that it is drawn on. The region that it is drawn on. The severity level of the defect. The side that the defect is on. Class: Function: Relationships: DefectType Contains the defect types and the color that is used in displaying it Belongs to a certain defect that is in a sample. Attributes colorstring (text) name (text) The color that is used to denote the specific defect. The name of the specific defect. Page 21

23 11 Prototype The prototype shows the menus and options for the inspection, as well as the picture used for the car models. It also demonstrates how information is displayed, selected, and added into the file. Furthermore, it also gives an idea of how the inspector information will be added in and all the information that will be delivered to the supervisor, which helps to figure out any missing requirements. You can locally store data on the ios system with CoreData, a SQLite database. This allows data to be saved in case of app closure or other failure. It includes the transfer of the data from the ipad to the project website for storage into a csv file. This utilizes HTTPS POST protocol to transfer over the data to a specific spot on the website. The prototype also includes the example reports from the csv data to be printed out and used within the vehicle plant. This gives a good example to the customer and whether or not the requirements are being met. We decided to go with a mobile app in order to create our prototype. The main reason for this is the group s lack of efficient knowledge of web programming. Using ios and an ipad was choosen as the group had more experience with Apple over Android. Android tablets would have been cheaper to utilize for this software, but Apple products are also more unified and similar compared to the numerous options for Android. Page 22

24 12 How to Run Prototype In order to run the prototype for the Car Finish Inspection system, there are a couple of requirements. The first need is an Apple ipad running on ios 9.0 or higher. This is required for the actual data entering for the defects per car. Along with this, an internet connection will be required by both the ipad and computer to transfer the data over from the ipad to the central computer ( team site currently) utilizing the HTTPS POST protocol. Also, in order to view the sample reports on our team s website, both an internet connection and a web browser will need to be utilized. Page 23

25 13 Sample Scenarios The first step of creating the report involves inputting the analyst name along with selecting the factory, checkpoint, and the shift that the report is part of. If John Doe was completing this, he d put in John Doe in the analyst field and select Lake Orion for the Page 24

26 factory, E Coat for the checkpoint, and Morning for the shift. He would then click Start to continue on with the report. After getting the basic information of the report, John will then get to the sample page. Here will be listed the various samples and whether or not they are completed. The Page 25

27 red sample above denotes that John has not finished that sample; it will turn green when done. John can click on the sample to change it or the + to add a new sample to the system. Once fully finished with the report, he will come back to this page and hit finish. After starting a sample, John will then be able to enter defects. Using the Left, Right, and Top tabs, John is able to change the view of the car for entering defects on the Page 26

28 top for example. Using the scroll data section, John can select the defect type of Mapping. He ll then select the corresponding severity as Low. The system then automatically puts in the Sample Side and Region of the defect based on the view and placement of the defect. Once done with each side, he will slide over the sections at the top making them green and marking them done. He can then hit back to add another sample. Page 27

29 After hitting finish on the report, John will arrive at the summary page. This page will show a quick overview of where the defects are. It is here that John will click Save to Device to finalized the data. Once John gets to a place with wireless internet, he will then be able to click the Send button. This will transfer the data over to the group website in order to be utilized in reports. Page 28

30 14 References [1] Systems and software engineering Vocabulary, International Organization for Standardization, Switzerland, December Located at CSE 435 website. [2] IEEE Recommended Practice for Software Requirements Specifications, The Institute of Electrical and Electronics Engineers Inc., New York, June Located at CSE 435 website. [3] Team 6 Website. Page 29

31 15 Point of Contact For further information regarding this document and project, please contact Prof. Marilyn Wulfekuhler at Michigan State University All materials in this document have been sanitized for proprietary data. The students and the instructor gratefully acknowledge the participation of our industrial collaborators. Page 30