Session 2 Getting started with a well-structured system specification COMP 320/420 Spring, 2018 Conrad Weisert The situation A representative approaches us. (or vice versa) He or she may be a. an executive with funds b. or a worker with a perceived need and may represent a. a department or organization inside our company b. or a potential outside customer He or she makes us aware of the possible need for a computer application system a. to replace an unsatisfactory old (computerized or manual) system b. or to exploit a new opportunity c. or to avoid a future penalty d. (or whatever) Our response We need to determine, at least tentatively, the scope of the proposed system. Who (by role or job function) will use it? What activities will be included? what ones are specifically excluded? What current systems, if any, will it replace? What information will the system provide? Until everyone (who?) agrees on the above, there's no point in proceeding with: Designing the system, Estimating what it will cost, Estimating when it can be ready. Two easy things we can do early Document the preliminary scope One effective technique is the context diagram, a trivial form of dataflow diagram Discuss and negotiate it with stakeholders Give a very rough range of estimates (min & max) Specify some principal system outputs, the information the system will produce. Note: These two activities are largely independent of methodology or choice of tools. COMP 320 / 420 1-4 copyright Conrad Weisert
Session 2a: Specifying System Outputs The importance of system outputs Why start with outputs? Modes and media Specifying output content Specifying format and presentation Avoiding false outputs COMP 320/420 Spring, 2018 Conrad Weisert What is a system output? A collection of information that is seen and used: a. either by end users (or customers) of the application system printed reports display screens other b. or by another application system or device files signals etc. What's the difference, if any, between information & data? What about other "outputs"? In I.T. the term output is also used to describe the result of a function or of an internal process. Such results are not system outputs or application outputs. They are seen not by users or other systems but by other components of the same system They are addressed (later) in internal system design or architecture, not by systems analysts but by software designers and programmers. The special importance of system outputs Often the very purpose of an application system ("information systems") The most visible components of an application system. End users understand outputs (or should) Suprisingly, many S.A. textbooks and courses don't emphasize (or even mention) system outputs! Outputs are just a special kind of data structure for them. COMP 320 / 420 5-8 copyright Conrad Weisert
Why start with outputs? Old fashioned analysts often started by specifying system inputs! Probably because reading inputs was the first thing the system would have to do upon starting operation. Also because the analyst had in mind a preconceived system architecture. But once we know what information the system must produce, we can derive many of: The data items that must be stored or computed. The formulas, processes, and decision rules (and the system inputs) needed for producing that information. Methodology independence Of all the ESD components, system output specifications are the least dependent on our choice of systems analysis methodology. They fit well with Structured Analysis, UML, Discrete Requirements Lists, "Agile" methods Prototyping etc.,etc.. Therefore they ought to be non-controversial and should be specified early by every systems analyst on every system development project. So, are they? Specifying an output The analyst will: 1. Identify the output and its purpose 2. Specify the content (i.e. the information) 3. (optional) specify the format or appearance (output prototype or sample) How can an analyst know (or discover) all that? Interviews with (or input from) end-user representatives Examination or observation of the current (old) system, if there is one. Experience, insight, and imagination Step 1: Identifying an output Why are these necessary? The analyst specifies: a name for the output the purpose of the output the distribution (who gets it or may see it) the frequency (or schedule) for producing it the medium (or mode) the content (list of data items) expected volume (avg. & max.) unusual security, confidentiality, or audit requirements usually using a form (paper or screen) provided by some C.A.S.E. tools If yours doesn't, then design your own. COMP 320 / 420 9-12 copyright Conrad Weisert
Specifying the purpose of an output This is usually straightforward and obvious However, be careful when replacing an existing (manual or computerized) system "We've always gotten that report!" A user may: feel threatened by losing a tool he or she has been using in everyday work, especially in working with other people (a status indicator?) like to examine areas not needed for his or her job (e.g. other employees' performance reviews) How can we handle that? Output frequencies or schedules Regular schedule daily, weekly, monthly, etc. On demand From whom? Why? When? On event content change / update exceptions, alarms, unusual conditions error Output Distribution List of people (roles) who either automatically get a copy each time it's produced or are authorized to view the output Step 2: Specifying output content` List of rigorously defined data items items from the data dictionary (next course session) or simple formulas on those data items What if the formulas aren't simple? Sequence, breaks, and totals What are those? Step 3 (optional): Specifying format In theory, user representatives ought to be able to review and approve output specifications, based on content, i.e the information to be produced: However, some potential users can be helped to understand by actually seeing what the output will look like. Such a presentation (printed report or screen display) is called an output prototype COMP 320 / 420 13-16 copyright Conrad Weisert
Pitfalls and downside of I-O prototypes The format and appearance may distract some user-reviewers from the content. Users' expectations may be misdirected: They may be surprised, even disappointed, if the output from the final system doesn't look exactly the same. Unnecessary constraint on the system designers. Obstacle to choosing a packaged application system product. Special output modes Typical outputs of computer application systems are composed of text, often in tabular form. However, keep in mind that modern computer systems can also easily generate: Graphs or plots of various kinds Audio speech synthesis E-mail UPC labels and other specialized codes What else? Avoiding false outputs Some information that comes out of a system are not considered to be system outputs. For example: prompt messages error messages progress / status indicators transaction confirmation messages Why? Therefore the analyst doesn't need to (and usually shouldn't) specify them. Who will? When? COMP 320 / 420 17-20 copyright Conrad Weisert