TCS2411 Software Engineering1 Software Requirements Analysis “What does the customer want?”

TCS2411 Software Engineering2 Lecture Objectives zTo understand the importance of specifying requirements correctly zTo discuss the different representations of requirements in the analysis model zTo illustrate the modeling of data elements in the problem domain

TCS2411 Software Engineering3 During Breakfast One Day... Nasi Lemak!

TCS2411 Software Engineering4 What Is Served? zNasi Lemak : Sambal : Cucumber : Peanuts ? : Egg? : Ikan Bilis ? : Chicken ? : Sotong ?

TCS2411 Software Engineering5 Expectations zStandard: Nasi Lemak + Sambal + Cucumber + Peanuts + Ikan Bilis zGreat: All above + Egg + Chicken/Sotong zDisappointing: Nasi Lemak + Sambal + Cucumber

TCS2411 Software Engineering6 What We Are Doing ABC Software!

TCS2411 Software Engineering7 The First Task Problem Models Solution Analysis Design Development Testing

TCS2411 Software Engineering8 Software Requirements Analysis zDeveloper and customer communicate to form the details of the software zDeveloper - interrogator, problem solver zCustomer - required functions & performance zProblems: yMisinterpretation yMisinformation yAmbiguity

TCS2411 Software Engineering9 Requirements Analysis Tasks 1.Problem Recognition: as perceived by the customer. 2.Evaluation & Synthesis: the analyst define data objects, evaluate the flow of information, define all software functions, understand system behavior, establish system interface characteristics and design constraints. 3.Modeling: models of data, information and control flow, and operational behaviors. 4.Specification: a model of the software is created and evaluated by both software engineers and customers. 5.Review: of software requirements specifications done by developer and customer.

TCS2411 Software Engineering10 Analysis Principles zInformation domain of a problem must be represented and understood zRequired functions must be defined zBehaviour of software must be represented zModels that depict information, function, and behaviour must be partitioned in a layered or hierarchical fashion zAnalysis process should move from essential info to implementation detail

TCS2411 Software Engineering11 More guidelines zUnderstand the problem before creating the analysis model zDevelop prototype zRecord origin and reason of requirements zUse multiple views zPrioritize requirements zEliminate ambiguity

TCS2411 Software Engineering12 The Analysis Model Data Dictionary Entity- Relationship Diagram Data Flow Diagram State-Transition Diagram

TCS2411 Software Engineering13 Analysis Model Elements zData Dictionary yContains descriptions of all data objects used zEntity-Relationship Diagram (ERD) yDescribes relationships between data objects zData Flow Diagram (DFD) yDescribes data flow & transformation zState Transition Diagram (STD) yDescribes system behaviour

TCS2411 Software Engineering14 Data Modeling zIdentification of ‘what’ elements from the problem domain that is relevant zGraphically represented by Entity- Relationship Diagram, which contains: yEntities yAttributes yRelationships

TCS2411 Software Engineering15 Entities zRepresentation of items from the problem domain that is applicable to the system zHas a set of attributes to describe it zDrawn as a labeled rectangle in ERD CustomerMember

TCS2411 Software Engineering16 Entity Examples zExternal entity – (anything that produces or consumes information) zThing (e.g. report or display) zOccurrence or events (e.g. phone call) zRole (e.g. salesperson) zOrganizational unit (e.g. accounting department) zPlace (e.g. warehouse) zStructure (e.g. File)

TCS2411 Software Engineering17 Attributes zProperties of the entity yname of an instance yDescription of an instance. yreference to another entity zOne or more attributes must be defined as identifier - “key” to find an instance of the entity. (e.g. ID number of a student). zSet of attributes may differ in different analysis

TCS2411 Software Engineering18 Relationships zAssociations between instances of one or more entity types that is of interest zUsually means that event has occurred, or there exists some natural linkage between entity instances zDrawn as line between entities, labeled with verb phrases Employee Parking Place is assigned is assigned to

TCS2411 Software Engineering19 Cardinality zSpecification of the number of occurrences of one object that can be related to the number of occurrences of another object zUsually expressed as ‘one’ or ‘many’ zPossible relationships: yOne-to-One yOne-to-Many yMany-to-Many

TCS2411 Software Engineering20 One-to-One Relationship MemberSpouse “Every member has a spouse” is married to is spouse of

TCS2411 Software Engineering21 One-to-Many Relationship MemberSpouse “Every member has one or more spouses” is married to is spouse of

TCS2411 Software Engineering22 Many-to-Many Relationship ParentChild “Every parent has one or more children, and every child has one or more parent” is parent of is child of

TCS2411 Software Engineering23 Modality zSpecifies whether the relationship is optional or mandatory zModality is 0 if relationship is optional yrepresented by dotted line in ERD zModality is 1 if relationship is mandatory yrepresented by straight line in ERD

TCS2411 Software Engineering24 Optional relationships MemberSpouse is married to is spouse of “Every member may have a spouse” MemberSpouse “Every member may have one or more spouses” is married to is spouse of

TCS2411 Software Engineering25 Example of Entity- Relationship Diagram Customer Order Item Order places placed by contains part of Product describes is a

TCS2411 Software Engineering26 References z“Software Engineering: A Practitioner’s Approach” 5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001 z“Software Engineering” by Ian Sommerville, Addison-Wesley, 2001 z“Modern Systems Analysis and Design” by Jeffrey A. Hoffer, Joey F. George & Joseph S. Valacich, Benjamin/Cummings, 1996