Business System Analysis and Design Notes

Skills by System Analyst:Working knowledge of information technology(The analyst must be aware of both existing and emerging information technologies),Computer programming, experience and expertise,General business knowledge,General problem-solving skills,Good interpersonal communication skills,Good interpersonal relations skills,Flexibility and adaptability,Character and ethics. Info sys architecture:provides a foundation for organizing various components of any info sys you care to develop. a unifying framework into which various stakeholders with different perspectives can organize and view the fundamental building blocks of information systems. Views of knowledge System owners view: Interested not in raw data but in information. (Business entities and business rules) System users’view: View data as something recorded on forms,stored in file cabinets,recorded in books and spreadsheets,or stored on computer. Focus on business issues as they pertain to data. Data requirement System designers’ view: Data structures,database schemas,fields,indexes,and constraints of particular database management system (DBMS). System builders’ view: SQL,DBMS or other data technologies Views of process System owners’view:Concerned with high-level processes called business functions. A cross-functional information system System users’view:Concerned with work that must be performed to provide the appropriate responses to business events. Business processes,Process requirements,Policy,Procedure, Work flow System designers’view:Concerned with which processes to automate and how to automate them. Software specifications System builders’view:Concerned with programming logic that implements automated processes. Application program,Prototyping Views of communication System owners’ view: Who? Where? What? System users’ view: Concerned with the information system’s inputs and outputs. System designers’ view: Concerned with the technical design of both the user and the system-to-system communication interfaces. System builders’ view: Concerned with the construction, installation, testing and implementation of user and system-to-system interface solutions *Basic principles of system development: Get the system users involved. Use a problem-solving approach. Establish phases and activities. Document through development. Establish standards. Manage the process and projects. Justify systems as capital investments. Don’t be afraid to cancel or revise scope. Divide and conquer. Design systems for growth and change. The need to improve: Performance Info Eco/controlcosts Control/Security Efficiency Service Phases for system development: scope definition, problem analysis, requirements analysis, logical design, decision analysis, physical designand integration, construction and testing, installation and delivery. Cross life-cycle activity: Fact-finding, Documentation and presentation Documentation, Presentation, Repository), Feasibility analysis, Process and project management Routes through the basic systems development phases: model driven development strategies (process, data, object modeling), Rapid application development (RAD), commercial application package implementation, system maintenance *Benefits of use case modeling: Provides tool for capturing functional requirements. Assists in decomposing system into man ageable pieces. Provides means of communicating with users/stakeholders concerning system functionality in language they understand. Provides means of identifying, assigning, tracking, controlling, and management system development activities. Provides aid in estimating project scope, effort, and schedule. The relationships that can appear on a use-case model diagram: Use case association relationship, extension use case, abstract use case, depends on, inheritance Use case – a behaviorally related sequence of steps (scenario), both automated and manual, for the purpose of completing a single business task. Steps for preparing a use-case model: Identify business actors. Identify business use cases. Construct use-case model diagram. Documents business requirements use-case narratives *Data modeling(database modeling)–a technique for organizing and documenting a system’s data. Data Modeling Concepts:Entity(class of persons, places, objects, events, or concepts about which we need to capture and store data),Attribute(descriptive property or characteristic of an entity. Synonyms include element, property and field), Data type(property of an attribute that identifies what type of data can be stored in that attribute),Domain(a property of an attribute that defines what values an attribute can legitimately take on),Default value(the value that will be recorded if a value is not specified by the user),Key(an attribute, or a group of attributes, that assumes a unique value for each entity instance. It is sometimes called an identifier),Subsetting criteria(an attribute whose finite values divide all entity instances into useful subsets. Sometimes called an inversion entry),Relationship(a natural business association that exists between one or more entities),Cardinality(the minimum and maximum number of occurrences of one entity that may be related to a single occurrence of the other entity),Degree(the number of entities that participate in the relationship),Recursive relationship(a relationship that exists between instances of the same entity),Foreign key(a primary key of an entity that is used in another entity to identify instances of a relationship),Parent entity(a data entity that contributes one or more attributes to another entity, called the child. In a one-to-many relationship the parent is the entity on the â€Å"one† side),Child entity(a data entity that derives one or more attributes from another entity, called the parent. In a one-to-many relationship the child is the entity on the â€Å"many† side),Nonidentifying relationship(relationship where each participating entity has its own independent primary key), Identifying relationship – relationship in which the parent entity’ key is also part of the primary key of the child entity,Generalization(a concept wherein the attributes that are common to several types of an entity are grouped into their own entity),Nonspecific relationship(relationship where many instances of an entity are associated with many instances of another entity. Also called many-to-many relationship) ,Sample CASE Tool Notations Entity relationship diagram (ERD):a data model utilizing several notations to depict data in terms of the entities and relationships described by that data. Logical Model Development Stages:1Context Data model(Includes only entities and relationships;To establish project scope). 2Key-based data model(Eliminate nonspecific relationships;Add associative entities;Include primary and alternate keys;Precise cardinalities). Fully attributed data model(All remaining attributes;Subsetting criteria). 4Normalized data model Normalize a logical data model to remove impurities that can make a database unstable, inflexible, and nonscalable. First normal form (1NF):entity whose attributes have no more than one value for a single instance of that entity,Any attributes that can have multiple values actually describe a separate entity, possibly an entity and relationship. Second normal form (2NF):entity whose nonprimary-key attributes are dependent on the full primary key,Any nonkey attributes dependent on only part of the primary key should be moved to entity where that partial key is the full key,May require creating a new entity and relationship on the model. Third normal form (3NF):entity whose nonprimary-key attributes are not dependent on any other non-primary key attributes. *Model:pictorial representation of reality. Logical model:nontechnical pictorial representation that depicts what a system is or does. Physical model:technical pictorial representation that depicts what a system is or does and how the system is implemented Process modeling:a technique used to organize and document a system’s processes. (Flow of data through processes,Logic,Policies,Procedures) Data flow diagram (DFD):a process model used to depict the flow of data through a system and the work or processing performed by the system. Synonyms are bubble chart, transformation graph, and process model. The DFD has also become a popular tool for business process redesign. Processes on DFDs can operate in parallel (at-the-same-time). DFDs show the flow of data through a system. Processes on a DFD can have dramatically different timing (daily, weekly, on demand) Context data flow diagram:a process model used to document the scope for a system. Also called the environmental model. Think of the system as a â€Å"black box. â€Å"2Ask users what business transactions the system must respond to. These are inputs, and the sources are external agents. 3Ask users what responses must be produced by the system. These are outputs, and the destinations are external agents. 4Identify any external data stores, if any. 5Draw a context diagram. Decomposition diagram:a tool used to depict the decomposition of a system. Also called hierarchy chart. Business System Analysis and Design Notes Skills by System Analyst:Working knowledge of information technology(The analyst must be aware of both existing and emerging information technologies),Computer programming, experience and expertise,General business knowledge,General problem-solving skills,Good interpersonal communication skills,Good interpersonal relations skills,Flexibility and adaptability,Character and ethics. Info sys architecture:provides a foundation for organizing various components of any info sys you care to develop. a unifying framework into which various stakeholders with different perspectives can organize and view the fundamental building blocks of information systems. Views of knowledge System owners view: Interested not in raw data but in information. (Business entities and business rules) System users’view: View data as something recorded on forms,stored in file cabinets,recorded in books and spreadsheets,or stored on computer. Focus on business issues as they pertain to data. Data requirement System designers’ view: Data structures,database schemas,fields,indexes,and constraints of particular database management system (DBMS). System builders’ view: SQL,DBMS or other data technologies Views of process System owners’view:Concerned with high-level processes called business functions. A cross-functional information system System users’view:Concerned with work that must be performed to provide the appropriate responses to business events. Business processes,Process requirements,Policy,Procedure, Work flow System designers’view:Concerned with which processes to automate and how to automate them. Software specifications System builders’view:Concerned with programming logic that implements automated processes. Application program,Prototyping Views of communication System owners’ view: Who? Where? What? System users’ view: Concerned with the information system’s inputs and outputs. System designers’ view: Concerned with the technical design of both the user and the system-to-system communication interfaces. System builders’ view: Concerned with the construction, installation, testing and implementation of user and system-to-system interface solutions *Basic principles of system development: Get the system users involved. Use a problem-solving approach. Establish phases and activities. Document through development. Establish standards. Manage the process and projects. Justify systems as capital investments. Don’t be afraid to cancel or revise scope. Divide and conquer. Design systems for growth and change. The need to improve: Performance Info Eco/controlcosts Control/Security Efficiency Service Phases for system development: scope definition, problem analysis, requirements analysis, logical design, decision analysis, physical designand integration, construction and testing, installation and delivery. Cross life-cycle activity: Fact-finding, Documentation and presentation Documentation, Presentation, Repository), Feasibility analysis, Process and project management Routes through the basic systems development phases: model driven development strategies (process, data, object modeling), Rapid application development (RAD), commercial application package implementation, system maintenance *Benefits of use case modeling: Provides tool for capturing functional requirements. Assists in decomposing system into man ageable pieces. Provides means of communicating with users/stakeholders concerning system functionality in language they understand. Provides means of identifying, assigning, tracking, controlling, and management system development activities. Provides aid in estimating project scope, effort, and schedule. The relationships that can appear on a use-case model diagram: Use case association relationship, extension use case, abstract use case, depends on, inheritance Use case – a behaviorally related sequence of steps (scenario), both automated and manual, for the purpose of completing a single business task. Steps for preparing a use-case model: Identify business actors. Identify business use cases. Construct use-case model diagram. Documents business requirements use-case narratives *Data modeling(database modeling)–a technique for organizing and documenting a system’s data. Data Modeling Concepts:Entity(class of persons, places, objects, events, or concepts about which we need to capture and store data),Attribute(descriptive property or characteristic of an entity. Synonyms include element, property and field), Data type(property of an attribute that identifies what type of data can be stored in that attribute),Domain(a property of an attribute that defines what values an attribute can legitimately take on),Default value(the value that will be recorded if a value is not specified by the user),Key(an attribute, or a group of attributes, that assumes a unique value for each entity instance. It is sometimes called an identifier),Subsetting criteria(an attribute whose finite values divide all entity instances into useful subsets. Sometimes called an inversion entry),Relationship(a natural business association that exists between one or more entities),Cardinality(the minimum and maximum number of occurrences of one entity that may be related to a single occurrence of the other entity),Degree(the number of entities that participate in the relationship),Recursive relationship(a relationship that exists between instances of the same entity),Foreign key(a primary key of an entity that is used in another entity to identify instances of a relationship),Parent entity(a data entity that contributes one or more attributes to another entity, called the child. In a one-to-many relationship the parent is the entity on the â€Å"one† side),Child entity(a data entity that derives one or more attributes from another entity, called the parent. In a one-to-many relationship the child is the entity on the â€Å"many† side),Nonidentifying relationship(relationship where each participating entity has its own independent primary key), Identifying relationship – relationship in which the parent entity’ key is also part of the primary key of the child entity,Generalization(a concept wherein the attributes that are common to several types of an entity are grouped into their own entity),Nonspecific relationship(relationship where many instances of an entity are associated with many instances of another entity. Also called many-to-many relationship) ,Sample CASE Tool Notations Entity relationship diagram (ERD):a data model utilizing several notations to depict data in terms of the entities and relationships described by that data. Logical Model Development Stages:1Context Data model(Includes only entities and relationships;To establish project scope). 2Key-based data model(Eliminate nonspecific relationships;Add associative entities;Include primary and alternate keys;Precise cardinalities). Fully attributed data model(All remaining attributes;Subsetting criteria). 4Normalized data model Normalize a logical data model to remove impurities that can make a database unstable, inflexible, and nonscalable. First normal form (1NF):entity whose attributes have no more than one value for a single instance of that entity,Any attributes that can have multiple values actually describe a separate entity, possibly an entity and relationship. Second normal form (2NF):entity whose nonprimary-key attributes are dependent on the full primary key,Any nonkey attributes dependent on only part of the primary key should be moved to entity where that partial key is the full key,May require creating a new entity and relationship on the model. Third normal form (3NF):entity whose nonprimary-key attributes are not dependent on any other non-primary key attributes. *Model:pictorial representation of reality. Logical model:nontechnical pictorial representation that depicts what a system is or does. Physical model:technical pictorial representation that depicts what a system is or does and how the system is implemented Process modeling:a technique used to organize and document a system’s processes. (Flow of data through processes,Logic,Policies,Procedures) Data flow diagram (DFD):a process model used to depict the flow of data through a system and the work or processing performed by the system. Synonyms are bubble chart, transformation graph, and process model. The DFD has also become a popular tool for business process redesign. Processes on DFDs can operate in parallel (at-the-same-time). DFDs show the flow of data through a system. Processes on a DFD can have dramatically different timing (daily, weekly, on demand) Context data flow diagram:a process model used to document the scope for a system. Also called the environmental model. Think of the system as a â€Å"black box. â€Å"2Ask users what business transactions the system must respond to. These are inputs, and the sources are external agents. 3Ask users what responses must be produced by the system. These are outputs, and the destinations are external agents. 4Identify any external data stores, if any. 5Draw a context diagram. Decomposition diagram:a tool used to depict the decomposition of a system. Also called hierarchy chart.