1. Modeling system requirements

2. Purpose of Models Models help an analyst clarify and refine a design. Models help simplify the complexity of information system for an analyst to focus on few aspects of the system at a time. Many different models can be used by the analyst when developing a system. Models help the analyst recall details of work previously completed.

3. Models serve a critical role in supporting communication among project team members and with system users. Analyst reviews models with a variety of users to get feedback on the analysts understanding of the system requirements. The requirements models produced by the analyst are used as documentation for future development teams when they maintain or enhance the system.

4. Types of models Mathematical models: A series of formulas that describe technical aspects of a system. They are used to represent precise aspects of the system that can be best represented by using formulas or mathematical notation. These models are examples of technical requirements. Mathematical notation is the most appropriate way to represent functional requirements

5. It is also the most natural way for scientific and engineering users to express requirements. An analyst working on scientific and engineering applications better be comfortable with math Mathematical notation is also sometimes efficient for simpler requirements for business sytems.

6. Descriptive models Not all requirements can be precisely defined with mathematics Descriptive models are narrative memos, reports, or lists that describe some aspect of a system. One example of descriptive model involves writing a process or procedure in a very precise way, referred to as structured english or pseudocode

7. Graphic models The most useful model is the graphical model. Graphical models include diagrams and schematic representations of some aspect of a system Graphical models make it easy to understand complex relationships that are too difficult to follow when described verbally. Some graphical models actually look similar to a real-world part of a system such as screen design or a report layout design

8. In graphical model, the analyst use symbols to represent more abstract things The key graphical models used for the analysis phase tend to represent the more abstract aspects of a system, because the analysis phase focuses on fairly abstract questions about system requirements without indicating the details of how they will be implemented

9. USE CASES Specifics for modeling the functional requirements of an information system A use case is an activity the system performs, usually in response to a request by a user. Techniques for identifying activities or use cases – List all users and think through what they need the system to do for their jobs. By focusing on one type of user at a time, an analyst can systematically address the problem of identifying use cases

10. Another approach is to start with the existing system and list all system functions that are currently included, adding any new functionality requested by users. Another approach is to talk to all users to get them to describe their goals in using the system.

11. USE CASE DIAGRAM Use case diagrams are diagrams used to show the various user roles and how those roles use the system. Use case diagrams are convenient ways to document system activities. Sometimes a single. Comprehensive diagram is used to identify all use cases for an entire system Other times, a set of smaller use case diagrams is used

12. Each use case must also be described in detail using use case narration. The objective of use case analysis is to identify and define all of the elementary business processes that the system must support. Use case is an activity the system carries out, usually in response to a request by a user of the system.

13. Unified Modeling Language Unified Modeling Language (UML) is a standardized general- purpose modeling language in the field of software engineering. The standard is managed, and was created by, the Object Management Group. UML includes a set of graphic notation techniques to create visual models of software-intensive systems.

14. CLASS DIAGRAM Classes of objects have attributes and associations. Cardinality also applies among classes. Class diagram is used to show classes of objects for a system. Rectangles represent classes, and the lines connecting the rectangles show the associations among classes.

15. Class diagrams shows a rectangle with two or three sections. The top section contains the name of the class, the middle section lists the attributes of the class, and the bottom section lists the important methods of the class. Class diagrams are drawn by showing classes and associations among classes.

16. Types of UML Class diagram Domain model class diagram – Each class symbol includes only two sections. Methods are not shown on a domain model class diagram. – UML notation requires class names to be capitalized. – Attributes begin with a lowercase letter.

17. Generalization/specialization Hierarchies They are based on the idea that people classify things in terms of similarities and differences. Generalizations are judgments that group similar types of things. Eg. Motor vehicles- cars, trucks, tractors. All motor vehicles share certain general characteristics, so a motor vehicle is a more general class.

18. Specializations are judgments that categorize different types of things. Eg. Special types of cars include sports cars, sedans, and sport utility vehicles. These types of cars are similar in some ways, yet different in other ways. A generalization/specialization hierarchy is used to structure or rank these things from the more general to the more special.

19. Each class might have a more general class above it, called a superclass. A class might have a more specialized class below it, called a subclass. Inheritance allows subclasses to share characteristics of their superclasses

20. Whole-Part Hierarchies Another way people structure information about things is by defining them in terms of their parts. Whole part hierarchies capture the relationships that people make when they learn to make associations between an object and its components. An examples is keyboard which is not a special type of computer but rather part of a computer.

21. Types of whole-part hierarchies Two types: aggregation and composition Aggregation is used to describe a form of association that specifies a whole-part relationship between the aggregate (whole) and its components (parts) where the parts can exist separately. Composition is used to describe whole-part relationships that are even stronger, where the parts, once associated, can no longer exist separately.

22. The UML diamond symbol is filled in to represent composition. Whole-part hierarchies serve mainly to allow the analyst to express subtle distinctions about associations among classes.

23. Design class diagram This diagram shows more about the actual design of the software.