System Design Specification

System Design Specification Guide

The system design specification presents the complete system design for an information system and is the basis for the presentations that complete the systems design phase. Following the presentations, the project either progresses to the systems development phase, requires additional systems design work, or is terminated.

System Design Specification

Table of Contents

1. Management summary (20 pts.)

a. Summary of requirements

b. Development to date

c. Provides a current status report

d. Summarizes project costs and benefits

e. Implementation schedule highlights

f. Any issues that management will need to address

2. System Components (40 pts.) << note that this section has the most points assigned.

a. System: This section contains the complete design for the new system, including the user interface, outputs, inputs, files, databases, and network specifications. You should include source documents, report and screen layouts, DFDs, and all other relevant documentation. You also should include the requirements for all support processing, such as backup and recovery, start-up processing, and file retention. If the purchase of a software package is part of the strategy, you must include any interface information required between the package and the system you are developing. If you use a CASE design tool, you can print design diagrams and most other documentation directly from the tool. See my notes in Appendix (Dr. MM).

3. System Environment (15 pts.)

a. Constraints, or conditions, affecting the system. Examples of operational constraints include transaction volumes that must be supported, data storage requirements, processing schedules, reporting deadlines, and online response times.

b. Requirements that involve operations

c. Hardware (Storage, Input / Output Devices)

d. Systems software, (Interface, Communications or data exchange)

e. Security

4. Implementation requirements (10 pts.)

a. Specify start-up processing

b. Initial data entry or acquisition

c. User training requirements

d. Software test plans

5. Time and cost estimates (15 pts.)

a. Detailed schedules

b. Cost estimates,

c. Staffing requirements

d. Total costs-to-date

6. Additional material

a. Other material can be included at the end of the system design specification. In this section, you might insert documents from earlier phases if they would be helpful to readers.

APPENDIX

Hello everyone, this section contains notes from prior classes. So, you’ll see some questions students have asked before. If you have any questions, please post in my Virtual Office.

In the PIR you were required to show some current as-is processes along with future requirements of the system. The spirit of the PIR was to show these in a conceptual/logical manner. No physical commitments were done i.e no specific technology was specified (HW, SW, UI, GUI, etc). So the PIR showed "what" needed to be done, but not the "how" and with "which" technology.

For the SDS you will need to go to the next level i.e. Need to make some physical choices, meaning decide on some specific technologies and provide details. However note that both PIR and SDS need to show the same "things" (data and process) but at different levels. So the SDS is an elaboration of the PIR with more details (physical/technology). The same theme of "input -> process -> output" is still valid but we need to elaborate with much more details. In the PIR we might have defined "input" as "Personal information of client", in the SDS we need to define the same "input" but as a more detailed and specific "data structure" e.g.

Personal_Client_Information(

First_name VARChar(25)

Last_name VARChar(50)

Date_of_birth Date

...)

Note: The format is not as relevant as the details and coverage provided.

The "output" of the "process" can be in a similar format as the above.

Concerning "process" or "requirement", during the PIR we specified them in general terms of what needs to be done e.g. Capture_order_info, Validate_credit_card, Seek_manager_approval, etc. Now during SDS we need to take each of these to the new physical level e.g.

1) For the "Capture_order_info", we need to specify some screen format along which technology (Browser based (html), mobile (native? html?), desktop (Windows, Mac, Linux)) ,

2) for the "validate_credit_card" we need to specify some processing logic when communicating with the merchant bank,

3) "seek_manager_approval", like the first process, we need to show user interface design/technology.

The student question that often comes up is which format to use when documenting SDS. You basically have three broad technology types:

1) structured methods (physical DFD i.e. data structures, flowcharts to define processes),

2) object oriented UML (object diagram, activity diagrams, etc.. but you can skip low level design like sequence diagrams), and

3) throwaway prototyping (use some screen painters/generators like Microsoft Access to document UI/GUI, flowcharts to describe what happens when buttons are clicked).

You can also show a combination of the above depending on your comfort level e.g. data structure + screen format from prototype + activity diagram.

No matter which format/technique you decide to use, you need to make sure that you cover the content of the "input -> process -> output" model discussed above, along with the required level of detail.

My recommendation is that you use Data Flow Diagrams (DFD): they are the easiest to learn and use. The entire notation consists of 4 symbols, as opposed to others which have tons more, and where it’s possible to make mistakes. So, if you have no preference on modeling tool, please opt for DFD. See: https://www.visual-paradigm.com/guide/data-flow-diagram/what-is-data-flow-diagram/

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Question 1: "we are required to implement a system from scratch, or are we allowed to recommend the purchase of an existing POS system? Or it is entirely possible to use a combination of these for instance by creating your own frontend and using a POS API, like Square for instance. Honestly, if this was a real world scenario I would just tell the club owners to purchase a POS system as that will be so much easier for them in the long run, but I assume that's probably not the goal of this assignment and you would like to see something from scratch? "

Good point. Yes if it was a real-life situation, most likely the we would not start from scratch since there are so many ready to use POS systems out there. The project would be one of integrating with an existing system. However for this class you need to show process models (input -> process -> output). Creating an entire POS for this project would be too much too. So you can tackle an entire POS then model couple processes only at the physical level.

Also the following is surely an option for you: "creating your own frontend and using a POS API, like Square for instance".

Again, the idea is to take couple processes from the PIR and to show them end-to-end (input -> process -> output) at the physical level.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Question 2: "Just looking for a little insight into how in-depth I need to go, and if we are designing from scratch are you expecting class diagrams, object diagrams, sequence diagrams, use case diagram in addition to a DFD and mockups? We are required to have 7 pages of text minimum which leaves only 5 pages for diagrams at most. Can I use cloud services and SDK's?"

No matter which format you decide to use (see above), you need to make sure that you cover the content of the "input -> process -> output" model discussed above, along with the required level of detail (Physical/technical). So from the PIR you need to select one or more requirement/process, and develop it into the physical level and provide all the details needed by the SDS. Again, the focus is not on what kind of diagrams you use as much as it is on coverage/completeness of needed information, as stated above i.e discuss each of the following along with selected technology/details "input -> process -> output".

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Question 3: "I found the System Components instructions in the template to be a bit vague and I just don't want to submit my assignment and find out I didn't include something you were expecting to see that knocks 20 points off my grade."

Yes the system components section shows the details of what the system does and there are various techniques to complete it as I described above. The main idea here is to show the developers what we want the system to do with specific technical details. So you have a lot of leeway in how you document this section. However you need to give the developers enough detail so that they can build the system without asking or having too many open questions, and to so with clear models, not simply textual descriptions. So if you stick to the theme of "input -> process -> output" and provide all the details as discussed above, using good modelling languages/techniques, you should be OK.

I further provided a breakdown of the grading scheme below for "2. System Components (40 pts.)". Please check it and let me know if you have any questions.

1. Management summary (20 pts.)

2. System Components (40 pts.)

2.1 - Processes shown at the appropriate level (operational i.e. not context or functional level), along with lower level processes/tasks/activities (10 points)

2.2 - Internal details of processes described in enough detail, using appropriate techniques i.e. avoid textual descriptions and rather use some appropriate modelling language (10points)

2.3 - Process inputs/outputs structures show enough physical details along with interface details like GUI or other (10points)

2.4 - Other requirements: like for all support processing, such as backup and recovery, start-up processing, and file retention (10points)

3. System Environment (15 pts.)

4. Implementation requirements (10 pts.)

5. Time and cost estimates (15 pts.)

6. Additional material