3. Software Requirements, Analysis &Specification Hoffer, Jeffrey A., et al (1996) Modern Systems Analysis and Design. Roger Pressman, Software Engineering: A Practitioner Approach Elias M. Awad (2000). System Analysis and Design (2 ed.]. Galgotia Publications (P) Ltd Reading Guideline CoSc3071 Fundamentals of Software EngineeringOverview + Analysis is the phase where we bridge the gap between the system requirements and the system design — Find requirement of the client/organization and specify it in such a way itcan be implemented (actually to be clearly understood by the designers) * Objective of Analysis — Identify customer’s needs. — Evaluate system for feasibility. — Perform economic and technical analysis. Allocate functions to system elements. Establish schedule and constraints. Create system definitions.Overview . What do we do during System Analysis — Understand purpose of the existing system + Identify inputs, outputs and process * Roles and responsibilities — Problem recognition — Evaluation and synthesis * focus is on what not how — Modeling — Specification — Review3.1. What is Requirement? * Requirement — features of system or system function used to. fulfill system purpose. * Focus on customer’s needs and problem, not on solutions: — Requirements definition document (written for customer). — Requirements specification document (written for programmer; technical staff).3.1. What is Requirement? * How do we get the requirement? — Requirement Determination/Identification + Plan how to do it * Gather Information + Review Identified Requirements — Prototype » Development and evaluation —JAD3.1. What is Requirement? * Required Characteristics of the Analyst — Impertinence * You should question everything — Impartiality * Your role is to find the best solution but not to satisfy what particular group of the system wants or otherwise — Relax constraints * Assume anything is possible and eliminate the infeasible. Do not acceptif people say “we used to do it this way so it has to continue likewise” — Attention to detail * Every fact must fit with every other fact. Don’t miss details because without some details the system may not work — Reframing * Be creative and look the organization ina different way3.2. Types of Requirement and Characteristics * Broadly classified into — Functional — Non Functional3.2. Types of Requirement and Characteristics - . j . — Factors that affects the general operation as well as the objective of the system — Things required so that the system exist and meet its objectives * input/output * processing * error handling3.2. Types of Requirement and Characteristics * Nonfunctional requirements: — Factors that affect the quality of the system + Performance * Dependability + End user criteria * Maintainability3.2. Types of Requirement and Characteristics * How do we know we have good requirement? — Verification + Are we building the product right? * refers to the set of activities that ensure that software (the product) correctly implements a specific function — What we implement, is it correct? — Validation + Are we building the right product? + refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements — Did we implement what the user requires?3.2. Types of Requirement and Characteristics * Correctness — Aspecification is correct if it represents the client’s view of the system — Each requirement shall describe something actually needed by the customer — Should not contradict itself — Externally - all desired properties are present. — Internally - no undefined references. — Properties and items in the system shall be clearly described + Requirements shall be verifiable (testable) + Requirements shall be traceable.3.2. Types of Requirement and Characteristics * Example (continued) — What is wrong with this requirement? + What is the Cataloguer? — Person, Hardware or Software ... + “required information .... of the book” ? — Type and detail of information, shall be described Tdenttfled Requiven Role identt fled: Cataloguer Role Description: The Cataloguer records required information of the book.3.2. Types of Requirement and Characteristics « Example (continued) — Identified Requirement in the Catalogue Section * Role Identified: Cataloguer * Process Identified: Cataloging * Role Description: The Catalogueris a personwho is responsible to record new book information in the database and produce cataloguecard. The required book information comprise ISBN, Book Title, Name of Author, Publisher, Barcode and Price of the book. — The LSEN ts unique code assigned to a book, which consists Latin character and digits. — The Barcode is produced after the catalogue card is produced — The Catalogue cava ts produced in thvee forms ...3.3. Requirement Identification * Requirement Determination/Identification — Plan how to do it — Gather Information — Review Identified Requirements * Prototype — Development and evaluation + JAD3.3. Requirement Identification * Background Analysis — Learn about the setting, the existing system and the physical processes related to the revised system + Who runs what + Who reports to whom + What is relationship betweenx and y? — E.g. relationship between catalogue section and circulation desk - ina library system * The nature and the type of interaction between processes + Etc.3.3. Requirement Identification * Information Gathering — What kind of information do we need? « About the firm * About the users + About the process — Techniques + Site Observation and Interview + Document Review/Investigation + Interview * Questionnaire3.3. Requirement Identification Policies Goals Objectives Organizational Structure Authority Job functions Information requirements Ete. Work flow Methods and Procedures Work Schedule Input data/info Outputs/reports etc } The Organization } User | The Work3.3. Requirement Identification . Traditional Methods for Requirement Identification — Interview — Questionnaire — Site/User observation — Document Review3.3. Requirement Identification Interview — Guideline + Plan the Interview — Identify interviewee: appointment, lead questions — Think aboutwhat you need to find out * Listen carefully and take notes (tape record if permitted) * Reviewnotes within 48hrs of the interview + Beneutral * Seek diverse views — Interview Questions * Open-ended questions * Close-ended questions — Thank the Interviewee at the beginning and at the end3.3. Requirement Identification Questionnaires — Choosing respondents + if more people to survey decide which set of people to send questionnaire to or which questionnaire to send to which group of people — Convenient: people at a local site or willing to get surveyed — Random sample: select any person from alist — Purposeful sample: select people who satisfy certain criteria — Stratified sample: select random set from each of many categories3.3. Requirement Identification Ce esG elec pilcoau tag Useful for... Specific purpose General information gathering Type of Close-ended Open-ended as wellas Close- questions ended Analysis Easy Difficult Clarity Has to be extremely clear Can be clarified on-site Time Required less time Requires more time Participant Could involvemany Could only involve only respondent representatives of the target group Co$c3071 - Fundamentals of SE an3.3. Requirement Identification Site/User Observation — People cannot always be trusted to reliably report their own actions * They may think some details are commonsense since they have done it for a very long time * They are afraid of the consequence of their answers — Often difficult to obtain unbiased data — People often work differently when being observed + Telling the task manual but doing something else — Formal systems Vs Informal system3.3. Requirement Identification 4. Document Review — Four types of useful documents * Written work procedure for an individual or a work group — Describes how a job is performed — Includes data and information used and created in the process of performing the job or task * Business form — Explicitly indicate what data flow in or out of a system and which are necessary for the system to work + Report generated by current systems — Enables the analyst to work backwards from the report to the data that generated it - company’s performance is past years * Description of current information system — Ifthe current system is computer based3.3. Requirement Identification * Modern Methods for Requirement identificati — Joint Application Design (JAD) — Prototype — CASE tools3.3. Requirement Identification . JAD — Similar to group interview as it brings together key users, managers and systems analysts — Purpose: eollectsystenmrequirements simultaneously from key people — Particular structure of roles and agenda is followed and analysts control the sequence of questions answered by users — Conducted off-site to keep participants away from distractions — may last from four hours to an entire week and may consist of many weeks3.3. Requirement Identification — Participants + Session Leader - organizes and runs the JAD * Users - key users of the current system + Managers of the workgroups who use the current system * Sponsor - needed to cover expenses + Systems Analysts - to learn from users and managers + Scribe - takes notes + IT Staff - other IT staff like programmers, database analysts3.3. Requirement Identification 2=Pretotypine — Repetitive process — Rudimentary version of system is built — Replaces or augments SDLC — Goal: to develop concrete specifications for ultimate system3.3. Requirement Identification 3. CASE Tools — CASE Tools are more effective during JAD sessions — Upper CASE tools are used + E.g. flow chart — Enables analysts to enter system models directly into CASE during the JAD session — Screen designs and prototyping can be done during JAD and shown to users ofSE3.3. Requirement Identification © Deliverables — Information collected from users interview transcripts, questionnaire responses, notes of observation Existing written information sample business forms and reports, procedure manuals, training manuals Computer-based information CASE repository contents and reports of existing system Understanding of organizational components Business objective Information people needs Data handled and when, how and who moves data Rules of data processing Key events —Scenarios3.4, Requirement Structuring * Modeling — Process Model — Logical Model — Data Model3.4, Requirement Structuring * A process model is a formal way of ime busi Data flow diagramming shows business processes and the data that flows between them3.4, Requirement Structuring * Understanding DFD — Data Flow Diagram allows to model how data flow in a system, be it + physical or logical * manual or computer-based — Two conventions * DeMarco and Yourdon * Gane & Sarson3.4, Requirement Structuring * Understanding DFD (Continued) Data Store Source/Sink Nawmé of Data Data Flow Name of bata DeMarco and Yourdon Gane & Sarson ofSE3.4, Requirement Structuring * Understanding DFD (Continued) Purchase Order PURCHASER ACADEMIC OFFICE Book List (Book_Title, Author) Purchase Order Order Log Book DeMarco and Yourdon List Procured3.4, Requirement Structuring * Understanding DFD (Continued) Purchasing ACADEMIC OFFICE Book List, (Book_Title, Author) Purchase Order PURCHASER Procured Book List Gane &Sarsonelt mi Cle lals | Exercise * Determine requirement of the Taxi (minibus) Service System — Define the service aspect — The taxi management from the taxi owner perspective is not our scopeExercise * Solution — What does one need to go by taxi? + Should know where to go + Should geta free seat + Should pay for a service — How does one know the taxi route? + One can read the Taxi Sign or request the taxi route information from the Driver Assistant (@2A) — Whatis a Driver Assistant ? + Driver Assistantisa person who is responsible for the passengershospitality. + Activities to be performed by the Driver Assistant includes — Informing the taxi route to the passengers — Managing the free seats — Collecting payment from passengers and returning changes for excess payment — Informing the destination of each passenger to the driver — Whatis a passenger? « Passengeris a person who requestand use the taxi service + Passenger should pay for the service when requested by the Driver AssistantExercise * Solution (Continued) — Identified Roles * Passenger: See previous slide + Driver Assistant : See previous slide — Identified Process + Payment Process: — aprocess of collecting Payment from Passenger — Payment has to be calculated for each Passenger based on his/her route selection — The Payment process has to produce Change for excess Payment + Route Reporting — A process of reporting the Destination of the route when Route Request is presented by a PassengerExercise * Solution (Continued) — Identified Input + Route Request — Information requested by a Passenger about the Destination of the taxi. + Payment = Amountto be calculated for a specific path in the route for each Passenger — Identified Output * Destination — Point found in the taxi route which is described by Name * Change — Amount to be calculated from excess payment. Itis the difference between the actual payment made by the passenger and the required paymentfor the service.Exercise * Solution (Continued) — We could identify more requirement such as the role of the Driver, communication between the Driver and the Driver Assistant, etc. + Make it more complete after the class — Let’s do the structuring using DFDExercise Route Request Route Request Driver Assistant Payment Request Route Reporting Destination Destination Passenger Payment Request Payment Process Payment Payment.3.4, Requirement Structuring 1. Aprocess has to give output and no process should give output without input f- -O -6-3.4, Requirement Structuring * Things we should know 2. No data directly flow from Data store to Data Store 1 —{L_ x * Sink/Source to DataStore [__}——>[]_ x Data Store to Sink/Source [__k——-{]__ %& * Sink/Source to Sink/Source [__}>.__] & i a Cf} mje epee3.4, Requirement Structuring * Things we should know 3. Data can not flow back to the process it leaves before it flows through other process xelt mi Cle lals | 3.4, Requirement Structuring Q* Context Diagram3.4, Requirement Structuring * Context Diagram - Example Route Request Se Taxi Service Driver Assistant3.4, Requirement Structuring * Functional Decomposition — An iterative process of breaking the description of a system down into finer and finer detail which creates a set of charts in which one process on a given chart is explained in greater detail on another chartelt mi Cle lals | 3.4, Requirement Structuring * Functional Decomposition - Example Handling Recording Borrowing Issuing Purchase Order Catalog Card Preparation Distribution Retuning Clearing Lost Book Management3.4, Requirement Structuring * Functional Decomposition — The decomposition results level after level by producing decomposed processes (subsystems) that make up the parent system/subsystem _p a . i . i ‘no sub-process can logically be broken down any further — Accordingly the functional decomposition entail decomposition of the DFDelt mi Cle lals | 3.4, Requirement Structuring * Decomposition of DFD : DFD Level-n Primitive DFD i Level-n diagram isa DED that is generated from n nested decomposition from a level-0 diagram3.4, Requirement Structuring * Decomposition of DFD ACADEMIC OFFICE Book List Procuring Purchase Order PURCHASER Procured Book List3.4, Requirement Structuring * Decomposition of DFD Order Log Book List Issuin, ACADEMIC Order | Book List iQ _| Purenase Order a F Purchase OFFICE Receiving Order PURCHASER Procured Book List Purchase Order Purchase Process3.4, Requirement Structuring * Balancing DFD — Insuring that information presented at one level of a DFD is accurately represented in the next level DFD. — The conservation of inputs and outputs to a data flow diagram process when that process is decomposed to a lower level3.4, Requirement Structuring * Types of DFD_ — Current Physical — Current Logical — New Logical — New Physical3.4, Requirement Structuring * Types of DFD — Current Physical + Process labels include the names of people or their positions or the names of computer systems that might provide some of the overall system’s processing * The label includes an identification of the technology used to process the data + Data flows and data stores are often labeled with the names of the actual physical media on which data flow or in which data are stored, such as file folders, compute files, business forms, or computer tapes 71 -Fundamentals of SE3.4, Requirement Structuring * Types of DFD — Current Logical * The current system is reduced to its essence, to the data and the processes that transform them, regardless of actual physical form. — New Logical * Could be identical with the current logical if the users are happy with functionality of the current system but had problems with how it was implemented * Often the new logical model will differ from the current logical model by having additional functions and the removal of obsolete functions as well as reorganization of inefficient flows3.4, Requirement Structuring * Types of DFD — New Physical + Represents the physical implementation of the new system + Reflect the decisions of the analyst about which system function including those added in the new logical model will be automated and which will be manualLogic Modeling 3.4, Requirement Structuring Logic modeling involves representing the \ bof ionalitwaoftl process represented in DFD * Where appropriate, each process on the lowest(primitive) level DFD will be represented with one or more of the following — Structured English — Decision table — Decision tree — State-transition diagram3.4, Requirement Structuring * Structured English — Uses subset of English vocabulary to express the process procedures + Name of process = action verbs — Eg. Read, Find, Write, Print, Sort, Move, Merge, Add, Subtract, ete. * Data flow and data store = noun phrase — Itis possible to use Structured English to represent all three process typical to structured programming * Sequence * Conditional statements * repetitionLogic Modeling 3.4, Requirement Structuring * Structured English Pam D1] OrderLog ¥ 12 Booklist ‘ACADEMIC Order Booklist Issuing [Purchase Order OFFICE Receiving Deena “Oras 4 —Y PURCHASER. iE Purchase | Purchase Order Process 1.1: Order Receiving Do READ next book-record BEGIN IF IF Quantity-requested is less than five THEN WRITE five in Quantity-column END IF UNTIL End-of-Book-List Procured Book List < Process [©3.4, Requirement Structuring * Decision Tables — Diagram of process logic where the logic is reasonably complicated Rules Pes $~ Student condien Course of Action A~ Academic Staff Stubs Member type SS - Student and Staff Book type Action eae T - Text Book Stubs i R - Reference Issue for Spot reading x x3.4, Requirement Structuring * Decision Tables — Amatrix representation of the logic of a decision, which specifies the possible conditions for the decision and the resulting action — Three parts in a Decision Table * Condition stubs — Lists the conditions relevant to the decision * Rules — Specifies which actions are to be followed for a given set of conditions * Action stubs — Lists the actions that result for a given set of condition3.4, Requirement Structuring * Decision Trees — Graphical technique that depicts a decision or choice situation as a connected series of nodes3.4, Requirement Structuring * Decision Trees Issue for Borrow Reference Academic staff Legend: 1, Isa Book requested? 2. What type of book is it? 3. Who request the book? 4, Did the instructor reserved the book Wait for book request3.4, Requirement Structuring ¢ State Transition Diagram — Well-suited to model most types of process logic which are time dependent + Prepare lost book reporting form + Find the catalog + Calculate payment + Prepare Clearance Member's Request - Be at the Laelsswe L3: Issue L2: Issue circulation Receipt Clearance Payment Order Desk 4, Clearing * Accept Receipt LS: Collect Clearancerem Cots ( ills) 3.4, Requirement Structuring * We don’t have details about the data which are flowing into and out of processes CG) ‘acapemic | 80% Ust OFFICE Book List Receiving Bb ome? Procured Book List Issuing Purchase Order Purchase Process ot Order Log PURCHASER3.4, Requirement Structuring * Data modeling is one of the important activity during system development — Characteristics of data are important during the design of database, programs, computer screens and printed reports — Data is more complex aspect of the information system, even more than the process — Relationship between data is important to determine efficiency of the system3.4, Requirement Structuring * Data modeling is about the foundation of ; ith i ; s model of the system — Class Diagrams = OO approach — E-R Diagrams = Structural approach3.4, Requirement Structuring * Analysis Phase => Conceptual Data Modeling * Design Phase => Logical and Physical Modeling3.4, Requirement Structuring ¢ E-R Notations NAME OF ENTITY Name of Relation ATTRIBUTE ———_+++ Mandatory 1 ——6¢ Optional Many ———K& Mandatory Many ——€ Many with maximum nLe miteye tas) 3.4, Requirement Structuring ¢ E-R Notations — Cardinality 2 o-k 1 Mandatory 1 cardinality Mandatory many (M) cardinality (1, 2, .... many) (nis a number for an upper limit, if one exists) Optional 0 or 1 cardinality Optional zero-many cardinality (0, 1, 2, .... many)3.4, Requirement Structuring * Mandatory many — E.g. Purchase order containing list of books PURCHSE Contains orpER 4 Book Contained in3.4, Requirement Structuring * Maximumn — E.g. Borrow limit of library members Borrow 4 STUDENT Po < BOOK Borrowed By3.4, Requirement Structuring * Optional many — E.g. Academic office ordering books ACADEMIC pReguests Lo ¢ BooK hs q OFFICE Requested By [00K |3.4, Requirement Structuring * Mandatory 1 — E.g. Borrowing text book for spot reading Take for Spot Read STUDENT Po TEXT BOOK Taken for Spot Reading3.4, Requirement Structuring * Begin the conceptual data modeling by developing a conceptual data model for the system being replaced -if the system exists3.4, Requirement Structuring * E-R data model — Three main constructs: + Entities * Attributes + Relationships3.4, Requirement Structuring * Entities — About which the organization wishes to maintain data * Person, place, object, event, or concept — Entity Type Vs Entity Instance3.4, Requirement Structuring * Attributes — Property or characteristic of an entity that is of interest to the organization/system — Candidate Key — Primary Key ° Eg. STUDENT: STUDENT ID, EMAIL, TEL, BATCH — Multivalued Attributes3.4, Requirement Structuring + Relationshi — Arelation is an association between the instances of one ore more entity types that is of interest to the organization/system Unary Binary Ternary Bg SoS SES3.4, Requirement Structuring oe — . — Also known as composite or gerund — It is a type of relationship through which many- to-many relationship is represented — It can be used for one-to-one as well but often such relationship ends up to be merged toa single entity3.5. Selecting Alternative Design Strategy Alternative Design Strategy Requirement Andlysis t = Time