1 / 82

Requirement Analysis

Requirement Analysis. Prof. Jonathan Lee Department of Computer Science and Information Engineering National Central University. Software Requirements. Requirement Functional requirement describes system services or functions

dillon-hendricks
Download Presentation

Requirement Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Requirement Analysis Prof. Jonathan Lee Department of Computer Science and Information Engineering National Central University

  2. Software Requirements • Requirement • Functional requirement describes system services or functions • Non-functional requirement is a constraint or a goal on the system or on the development process • User (Customer) requirement • A statement in natural language plus diagrams of the services the system provides and its operational constraints • Requirements specification • A structured document for detail description of the system services. • Written as a contract between client and developer

  3. Characteristics of Requirements • Incomplete Requirements • Most software systems are complex, that developer can never fully captured during the system development, therefore, requirements are always incomplete. • Inconsistent Requirement • Different users have different requirements and priorities. There is a constantly shifting compromise in the requirements. • Prototyping is often required to clarify requirements.

  4. Requirements Engineering1 • Requirements elicitation • Determine what the customer requires • Requirements analysis • Understand the relationships among various customer requirements • Requirements negotiation • Shape the relationships among various customer requirements to achieve a successful result • Research on requirements trade-off analysis (formulating as goals) • Requirements specification • Build a form of requirements

  5. Requirements Engineering2 • Software modeling • Build a representation of requirements that can be assessed for correctness, completeness and consistency. • Requirements validation • Review the model • Requirements management • Identify, control and track requirements and the changes.

  6. Requirements Elicitation1 • Two sources of information for the requirements elicitation process • User (customer) • Application domain • Asking • Ask users what they expect from the system • Interview, brainstorm and questionnaire • Task analysis • High-level tasks can be decomposed into sub-tasks • Scenario-based analysis • Study instances of tasks • A scenario can be real or artificial

  7. Requirements Elicitation2 • Form analysis • A lot of information about the domain can be found in various forms (examples in ERD slides) • Forms provide us with information about the data objects of the domain, their properties, and their interrelations • Natural language description • with background information to be used in conjunction with other elicitation techniques such as interviews • Derivation from an existing system • Take the peculiar circumstances of the present situation into account (examples in ERD slides) • Prototyping

  8. Requirement Analysis • Information domain analysis • information flow: data transformation • data content: data dictionary • data modeling • Functional and behavioral representation • function: process transformation • behavior: state transition diagram • Interfaces definition • function/process interface • Problem partition and abstraction • at different levels of abstraction • classification and assembly structure

  9. Software Modeling • Purpose • focus on those qualities of an entity that are relevant to the solution of an application problem • abstract away those that are irrelevant • Model: an abstraction for • Understanding before (actually) building • Communication • Visualization • Reducing complexity • Methodology: build (analyze) a model of an application domain

  10. Application and Solution Domain1 • Application Domain (Requirements Analysis) • The environment in which the system is operating • Solution Domain (System Design, Object Design) • The available technologies to build the system

  11. The Analysis Process build a prototype requirements elicitation develop Specification the problem Review create analysis models

  12. Traditional Software Engineering Software Systems Function Behavior Data Data Flow Diagram Entity-Relation Diagram State Transition Diagram

  13. ERD DFD Structured chart Database Tables Structured Screen & Report English From Analysis to Design: A Traditional Approach

  14. Entity-Relationship Diagram1 • Entity • Primary things an organization collects and records information about. (noun) ( ) • E.g. persons, products, places, etc. • Relationship • Linkage between entities. (verb) ( ) • E.g. Persons perform jobs, Jobs consist-of tasks • Cardinality • Identify how many instances of one entity are related to how many instances of another entity.

  15. Entity-Relationship Diagram2 Persons M:N 1:1 Persons 1:N Jobs • Direction • using an arrow pointing to the object of the action. • Examples serve perform consist_of Jobs Customers Tasks Serve Persons Customers Perform Consist-of Tasks Jobs

  16. Assist Faculty Students Advice Take Teach Courses Entity-Relationship Diagram3 • Attributes: Properties to describe an entity • key attribute (key, identifier) to characterize the specific entity (to retrieve a single entity occurrence (instance)) • unique: to ensure that no other record has the same identifier. • unchanging: to ensure that it always refers to the same thing.

  17. Entity type Key attribute Attribute e.g. actual data Students Student_id name phone Entity occurrence 50416938 Doakes,, Jane 242-7147 71426006 Blough, JO 426-4141 • Student is an entity about which a university stores info such as the Student_id, name, and phone. • Compound keys: made up of a number of different subkeys to produce a unique identifier • e.g. course number + section number + term • The difference between an entity and an attribute is that attributes are atomic. • i.e. Attributes have no further attributes that describe them. Entities can be further described by their attributes.

  18. Entities Keys Attributes name credits Courses Course_id Course_id Section_id Faculty Sections Meeting_day Meeting_time Room Course_id Section_id Meeting_id Meetings Advanced Features1 • Kernel and characteristic entities • Entities can be described by other subsidiary entities in a hierarchical fashion. • to store related values of one of the attributes of an entity.

  19. Advanced Features2 • The highest entity type in the hierarchy is called a kernel entity, which has a unique identity that does not depend on the existence of any other entity type. • Characteristic entities: to record the repeated characteristics of the kernel entity. • e.g. Course is a kernel entity, Sections and Meetings are characteristic entities describing the characteristics of Courses. • The unique identifier for the characteristic entities is a multiple key. • e.g. Course_id + Section_id are needed to uniquely identify a section.

  20. Is_Parent_of Is_Married_To Person Is_Child_of Advanced Features3 • Recursive relationships: an entity is related to itself • e.g. • for retrieving all family relationships

  21. Teach Take Courses Faculty Students Contain Occupy Sections Rooms Have Meetings Advanced Features4 • N-ary relationships • e.g. • An example

  22. Student number _____ name ________ Year of program ____ GPA ___ Scholarships Receive Apply for Students names of Scholarship applied for request Reference Letters Requested form: (names and addresses) Referees Where to look for information? • existing forms • forms organize the data and remind what to collect. • It is common in manual systems to provide large amounts of redundant data. • e.g. Scholarship Application Form

  23. Existing file structures • Frequently organizations have a collection of application programs that do not link to each other. They may require complex programs to transform data used by one application into a form used by another one. • e.g. existing student record system Accounts:Account_id, Label Buildings:Building_id, Name, Address. Courses:Course_id, Course_Name, Credits. Course_Program:Course_id, Program_id Departments:Department_id, Department_Name. Enrolled:Student_id, Course_id, Section_id, Year, Term, Grade. Faculty:Faculty_id, Name, Address, Birthday. Fee_Payments:Student_id, Account_id. Prerequisites:Course_id, Pre1, Pre2, Pre3. Programs:Program_id, Program_Name. Rooms:Building_id, Room_id, Size, Type. Sections:Course_id, Section_id, Year, Term, Faculty_id (Meeting_id, Building_id, Room_id, Day, Time) ... Students:Student_id, Name, Address, Birthday.

  24. Kernel entities: single keys, such as: Accounts, Buildings, Courses, Departments, Faculty, Prerequisites, Programs, and Students • Characteristic entity vs. Relationship (rules) • kernel entity (or characteristic entity)’s key + not part of the key of any entity => characteristic entity • multiple keys are combinations of keys for other entities => M:N relationships • e.g Course_program: course_id, program_id... Enrolled: students_id, course_id,... • e.g Rooms: building_id <---- from building’s room_id <--- not identified precisely characteristic entity

  25. Buildings Accounts Referees fee-payment applied-for Scholarships Rooms Students receive Meetings Sections Courses course-program Faculty Departments Programs ERD from existing forms and files

  26. Testing ERD • No identification key for entity • Two or more entities have the same key • Many relationships to a single entity • Two or more relationships between the same entities • N-ary relationship • An entity has no relationship

  27. Extended Entity-Relationship Model • To define the logical content of the database • Extension in two dimensions: • to document the attribute of each entity • to document the semantic meaning of the relationships

  28. Define Attributes • Attributes: an elementary item of recordable data that cannot be further subdivided into meaningful data items. (Field or descriptor) • with two distinguishing features: • atomic fact: an attribute cannot have attributes of its own. • single value: an attribute cannot have more than one value for any single entity occurrence. • If there is more than one value for the same entity occurrence, a new characteristic entity must be created to contain the multiple values.

  29. Define Attributes • Primary key: to identify uniquely each occurrence of an entity, with the following properties: • unique • unchanging • never has a null or missing value • can have more than one attribute to create a unique key. • a single attribute: an atomic key. • multiple attributes: a compound key. • dataless keys are not subject to change in the way that keys made up of data items often do. • Alternate key: to provide a choice of identifiers.

  30. Define Attributes • Foreign key: to create a link with another entity, e.g. PROGRAM_ID is a foreign key linking STUDENTS to PROGRAMS. • Null OK: to indicate whether this attribute can ever have a null value. • if an attribute does not exist for some occurrences of an entity. • if it exists but is not know at the time the entity occurrence is recorded. • foreign key can have a null value if the relationship that they map is optional. • Type: types of attributes. • Width: max number of characters or digits.

  31. Define Attributes • Example: Entity STUDENTS ATTRIBUTE PRIMARY KEY FOREIGN KEY NULL OK TYPE WIDTH ID X 9 STUDENT_ID CHAR SURNAME 20 FIRSTNAME CHAR 20 PROGRAM_ID X ID 9

  32. Semantics of the Relationships • Relationships • Extension to allow for • optionality: to determine whether the linked entities must always be linked. • existence dependency: to determine whether the existence of an entity occurrence depends on the existence of an occurrence of anther entity. • abstractions: permit the definition of a hierarchy of entities with rules about how the levels of the hierarchy are related.

  33. (OPTIONAL) (MANDATORY) STUDENTS STUDENTS COURSE REFEREES Semantics of the Relationships • Optionality: • Mandatory: If the relationship between entities A and B is mandatory, then each instance of A must correspond to an instance of B • Optional: If it is optional at the end of A, then some instance of A can be recorded that has no relationship to any instance of B • e.g.

  34. Semantics of the Relationships • Existence Dependency • to describe the relationship between characteristic entities and kernel entities Courses optionally have one or more sections HAVE COURSE SECTIONS Courses must have one of sections HAVE SECTIONS COURSE

  35. ATHLETES MUSICIANS STUDENTS Semantics of the Relationships • Abstractions • the more specific entities inherit the properties of the more abstract entities • specific entities are collected into subtypes that share common properties with the more general entity, called a supertype • overlapping subtypes (or aggregation relationship) • IS-PART-OF ( ) • e.g. • optional

  36. Semantics of the Relationships • Mutually exclusive subtypes (or generalization relationship) • IS-A ( ) • e.g. • existence dependency STUDENT UNDER GRADUATES

  37. ENROLL_IN STUDENTS SECTIONS Semantics of the Relationships • Convert M:N Relationships • Problems • Not specific enough for the detailed modeling entities • e.g. • does not provide a way of telling which of the many possible sections a particular student is actually enrolled in. • does not provide a way of telling which of the many actual students are enrolled in a particular section.

  38. Semantics of the Relationships • Solution • convert M:N relationship into an intersection entity (or association entity). • an M:N relationship usually represents a transaction that links the related entities. • can be identified by asking “what event or transaction cause the M:N relationship to occur”. • Intersection entity (association entity) • To represent a relationship about which we wish to maintain some information.

  39. Semantics of the Relationships STUDENTS ENROLLMENT SECTIONS John Mary Tania John ACC-1 John FIN-1 John STA-1 Mary ACC-1 Tania FIN-2 ACC-1 STA-1 FIN-1 FIN-2 STUDENTS SECTIONS ENROLLMENT

  40. EER Model of The Student Subsystem ENROLLMENTS EERM STUDENTS association entities REGISTRATIONS PROGRAMS OFFERINGS COURSES characteristic entities SECTIONS MEETINGS FACULTY

  41. To Sharpen Your EERM Skill1 Job_Description Tasks Position Management Staff Skills Benefits Stock_Options Pensions Employees

  42. To Sharpen Your EERM Skill1 • Answer the following questions based on the EERM on the previous slide: • (1) Does every job description have a related position? • (2) Can a task exist without a related job description? • (3) Can a task be part of more than one job description? • (4) Can a skill exist without a related task? • (5) Can an employee be both staff and management at the same time?

  43. To Sharpen Your EERM Skill1 • (6) How many staff can a manager supervise? • (7) Which employees get both a pension and stock options? • (8) Can a manager get both pensions and stock options? • (9) Do all managers get both pensions and stock options? • (10) Does every recorded position gave an employee in it?

  44. To Sharpen Your EERM Skill2 • Draw EERM based on the statements below: • (1) A country has a capital city. • (2) A dining philosopher is using a fork. • (3) A file is an ordinary file or a directory file. • (4) Files contain records. • (5) A polygon is composed of an ordered set of points. • (6) A drawing object is text, a geometrical object, or a group.

  45. To Sharpen Your EERM Skill2 • (7) A person uses a computer language on a project. • (8) Modems and keyboards are input/output devises. • (9) Object classes may have several attributes. • (10) A person plays for a team in a certain year. • (11) A route connects two cities. • (12) A student takes a course from a professor.

  46. To Sharpen Your EERM Skill3 • Apply ERD and EERM to model the text description below. • (a) A person has a name, address, and social security number. A person may charge time to projects and earn a salary. A company has a name, address, phone number, and primary product. A company hires and fires persons. Person and Company have a many-to-many relationship.

  47. To Sharpen Your EERM Skill3 • (b) There are two types of persons: workers and managers. Each worker works on many projects; each manager is responsible for many projects. A project is staffed by many workers and exactly one manager. Each project has a name, budget, and internal priority for securing resources.

  48. To Sharpen Your EERM Skill3 • (c) A company is composed of multiple departments; each department within a company is uniquely identified by its name. A department usually, but not always, has a manager. Most managers manage a department; a few managers are not assigned to any department. Each department manufactures many products; while each product is made by exactly one department. A product has a name, cost, and weight.

  49. Components of Structured Analysis process PSPEC processing narrative data & external entity PDL process data item E-R diagram(data modeling) DFD data store Data Dictionary (content) quasicontinuous data flow control process SA control item control store multiple instances of the same process control item CFD (CSPEC bar) a reference to CSPEC control CSPEC STD PAT

  50. Structured Analysis: Modeling Technique • model: describe information(data & control), flow, content. • control-oriented applicationsdeficiency • data-intensive applications

More Related