Structured Systems Analysis & Design UNISA studies – Chap 1 Objectives of Chapter 1 * Explain the key role of a system analyst in business. * Describe the various types of system and technology an analyst might use. * Explain the importance of technical skills, people skills and business skills for an analyst. * Explain why ethical behaviour is crucial for a system analyst’s career. * Describe various job titles in the field and places of employment where analysis and design work is done. * Discuss the analyst’s role in strategic planning for an organization. * Describe the analyst’s role in systems development projects.
Let me just say before I go into these notes that I find subjects like these extremely amusing & frustrating because of the disparity between the theoretical and the actual implementations in the “working world”. That being said, passing this course is a requirement for my degree. Key Words & Definitions for the Chapter * System Analysis – the process of understanding and specifying in detail what the information system should accomplish * System Design – the process of specifying in detail how the many components of the information system should be physically implemented. System Analyst – a business professional who uses analysis and design techniques to solve business problems using information system. * Information System – a collection of interrelated components that collect, process, store, and provide as output the information needed to complete the business tasks. * System – a collection of interrelated components that function together to achieve some outcome. * Subsystem – a system that is part of a larger system. * Functional Decomposition – dividing a system into components based on subsystems that are further divided into smaller subsystems. System Boundary – the separation between a system and its environment that inputs and outputs must cross. * Automation Boundary – the separation between the automated part of a system and the manual part of a system. (Different Systems) * CRM (Customer Relationship Management) – a system that supports marketing, sales, and service operations involving direct and indirect customer interaction. * SCM (Supply Chain Management) – a system that seamlessly integrates product development, product acquisition, manufacturing, and inventory management. AFM (Accounting & Financial Management) – a system that records accounting information needed to produce financial statements and other reports used by investors and creditors. * HRM (Human Resource Management) – a system that supports employee-related tasks such as payroll, benefits, hiring, and training. * Manufacturing Management System – a system that controls internal production processes that turn raw materials into finished goods. * Knowledge Management System – a system that supports the storage of and access to documents from all parts of the organization. Collaboration Support System – a system that enabled geographically distributed personnel to collaborate on projects and tasks.
* Business Intelligence System – a system that supports strategic planning and executive decision making. * ERP (Enterprise Resource Planning) – a process in which an organization commits to using an integrated set of software packages for key information systems. * Database – a centrally managed collection of data that is accessible to many users and systems at the same time. Tools – software products used to help develop analysis and design specifications and completed system components. * Techniques – strategies for completing specific system development activities. * Soft Skills – skills in nontechnical areas such as interviewing, team management, and leadership. * Hard Skills – skills in technical areas such as database design, programming, and telecommunications. * Strategic Planning – a process during which executives try to answer questions about the company, such as where the business is now, where they want to be, and what they have to do to get there. Information Systems Strategic Planning – the plan during the technology and applications that the information systems function needs to support the organization’s strategic plan. * Business Process Reengineering – a technique that seeks to alter the nature of the work done in a business function, with the objective of radically improving performance. * Application Architecture Plan – a description of the integrated information systems that the organization needs to carry out its business functions. Technology Architecture Plan – a description of the hardware, software, and communications networks required to implement planned information systems. The Analyst as a Business Problem Solver System analysis and design focuses on understanding the business problem and underlining the approach to be taken to solve it. The challenge of the analyst is to select the best solution with the fewest risks and most benefits. A system analyst can best be described as someone who uses information technology to solve business problems. A typical decision process followed is outlined below…
Systems that Solve Business Problems One can divide a system into many subsystems, which in return can be further divided into subsystems. This approach of dividing a system into components is referred to as functional decomposition. Every system has a boundary between it and its environment. Any inputs and outputs must cross the system boundary. In my experience it has been at the system boundary where the most challenges occur in system development The automation boundary is the boundary between automated systems and humans.
On one side of the boundary are the humans, on the other side are the other systems. Required Skills of the Systems Analyst System analysts require several skills including… * Understanding how to build information systems (Technical Knowledge / Technical Skills) * Understanding the business (Business Knowledge / Business Skills) * Understanding people (People Knowledge / People Skills) A system analyst should understand the fundamentals of the following technical skills * Computers and how they work File, database, and storage hardware and software * Input and output hardware and software * Computer networks & protocols * Programming languages, operating systems, and utilities * Communication and collaboration technology such as digital telephones, video conferencing and web based document management systems. A system analyst needs to know a lot about tools & techniques for developing systems including… * Software packages such as Intuit Quickbooks (Accounting),
Microsoft Access (DB), and Adobe Dreamweaver (Design), * Integrated Development IDE’s such as Oracle JDeveloper and Microsoft Visual Studio. * Computer-aided visual modeling tools such as Rational XDE Modeler, Visible Analyst & Embarcadero Describe * Automated testing tools, configuration management tools, software library management tools, etc. Techniques are strategies for completing specific system development activities. some examples of techniques include… * Project planning techniques * Cost/benefit analysis techniques Interviewing techniques * Requirements modeling techniques * Architectural design techniques * Network configuration techniques * Database design techniques The analyst will also need to have business knowledge & business skills. Some examples of this include… * What business functions do organizations perform * How are organizations managed * What type of work goes on in organizations The more an analyst knows about how an organization works, the more effective he can be Analysis Related Careers
There are many career opportunities, a few that were mentioned in the book include… * Sales & support of ERP Software * Business analysts for user organizations * Auditing, compliance, and security * Web development There are many job titles that might describe an analyst, a few that were mentioned in the book include… * Programmer analyst * Business systems analyst * System liaison * End-user analyst * Business consultant * Systems consultant * Systems support analyst * Systems designer * Software engineer System architect * Web architect * Webmaster * Web developer The Analysts Role in Strategic Planning An analyst is usually involved in strategic planning. They can be called to assist in special projects with executives or to help implement the application architecture plan. In an ideal world, a comprehensive information system planning project would solve all of the problems that information systems managers face, however because the world is continually changing, plans are continually being changed and evaluated.
The Analyst as a System Developer In this chapter we covered many different aspects of a system analyst, however… The main job of an analyst is working on specific information systems development projects. The remaining texts of the book will cover the following… * Part 1 – The System Analyst * Part 2 – System Analysis Tasks * Part 3 – System Design Tasks * Part 4 – Implementation and Support Structured Systems Analysis & Design UNISA studies – Chap 2 Objectives of Chapter 2 Explain the purpose and various phases of the traditional systems development life cycle (SDLC) * Explain when to use an adaptive approach to the SDLC in place of the more predictive traditional SDLC * Explain the differences between a model, a tool, a technique, and a methodology * Describe the two overall approaches used to develop information systems: the traditional approach and the object orientated approach * Describe the key features of current trends in system development: the Unified Process (UP), Extreme Programming (XP), and Scrum * Explain how utomated tools are used in system development ————————————————- Key Words & Definitions project – a planned undertaking that has a beginning and an end and that produces a desired result or product * systems development life cycle (SDLC) – the entire process of building, deploying, using, and updating an information system * predictive approach – an SDLC approach that assumes the development project can be planned and organized in advance and that the new information system can be developed according to plan
* adaptive approach – an SDLC approach that is more flexible, assuming that the project cannot be planned out completely in advance but must be modified as it progresses * phases – related system development activities which are grouped into categories of project planning, analysis, design, implementation, and support * waterfall model – a SDLC approach that assumes the various phases of a project can be completed sequentially – one phase leads into the next phase * spiral model – an adaptive SDLC approach that cycles over and over again through development activities until a project is complete * prototype – a preliminary working model showing some aspect of a larger system * iteration – system development process in which work activities – analysis, design, implementation – are done once, then again, and yet again on different system components they are repeated until the system is closer to what is ultimately needed. incremental development – a development approach that completes parts of a system in several iterations and then puts them into operation for users * project planning – the initial activities of the SDLC, whose objective is to identify the scope of the new system and plan the project * analysis activities – the activities of the SDLC whose objective is to understand the user needs and develop requirements * problem domain – the area of the user’s business for which a system is being developed * design activities –the activities of the SDLC during which the system and programs are designed * application – the portion of the new information system that satisfies the user’s needs in the problem domain * implementation activities – the activities of the SDLC during which the new system is programmed and installed * support activities – the activities of the
SDLC whose objective is to keep the system running productively after it is installed * help desk – the availability of support staff to assist users with any technical or processing problem associated with an information system * system development methodology – comprehensive guidelines to follow for completing every activity in the systems development life cycle, including specific models, tools, and techniques * model – a representation of an important aspect of the real world * tool – software support that helps create models or other components required in the project * technique – a collection of guidelines that help an analyst complete a system development activity or task * integrated development environment (IDE) – tools that help programmers with a variety of programming tasks * visual modelling tools – tools that help the analyst create and verify important system models, often generating program code * structured approach – system development using structured analysis, structured design, and structured programming techniques * structured program – a program or program module that has one beginning and one ending, and for which each step in the program execution consists of sequence, decision , or repetition constructs * top-down programming – dividing more complex programs into a hierarchy of program modules * structured design – a technique providing guidelines for deciding what the set of programs should be, what each program should accomplish, and how the programs should be organized into a hierarchy
* structure chart – a graphical model showing the hierarchy of program modules produced by the structured design technique * structured analysis – a technique used to define what processing the system needs to do, what data it needs to store and use, and what inputs and outputs are needed * data flow diagram (DFD) – a structured analysis model showing the inputs, processes, storage, and outputs of a system * entity relationship diagram (ERD) – a structured analysis and information engineering model of the data needed by a system * information engineering – a traditional system development methodology thought to be more rigorous and complete than the structured approach, because of its focus on strategic planning, data modelling, and automated tools * object-oriented approach – an approach to system development that views an information system as a collection of interacting objects that work together to accomplish tasks * object – a thing in the omputer system that can respond to messages * object-orientated analysis (OOA) – defining all of the types of objects that do the work in the system and showing what use cases are required to complete tasks * class diagram – a graphical model used the object orientated approach to show classes of objects in the system * Unified Process (UP) – an object oriented system development methodology offered by IBM’s Rational Software * repository – a database that stores information about the system in a visual modelling tool, including models, descriptions, and references that link the various models together. ————————————————- The System Development Life Cycle (See wiki for a more detailed explanation)
The entire process of building, deploying, using, & updating an information system is called the systems development life cycle. A SDLC may vary in size and the time, and can be just a few days to several years depending on its scope. In today’s diverse development environment there are many different approaches to developing systems, and each is based on a different SDLC’s. Although it is difficult to find a single, comprehensive classification system that encompasses all of the approaches, one useful technique is to categorize SDLC approaches according to whether they are more predictive or adaptive. A predictive approach is one which assumes that the new system can be developed according to plan.
This approach is useful if the system is well understood and defined. When applying a predictive approach very few changes are done to the system once the final plan is approved. A adaptive approach is one where the exact requirements of a system or the user’s needs are not well understood. In this situation, the project cannot be planned completely in advance, but the system can still be built and as the needs are better defined modifications to the system are done. Predictive approaches are considered more traditional and were used extensively in the 80’s and 90’s. Many newer adaptive approaches have been adopted since the 90’s and are currently used.
It is important to recognize that any project will have a mix of both the predictive and adaptive elements. The Traditional Predictive approaches to the SDLC There are five main phases to the predictive approach: 1. Planning – Identify scope, ensure feasibility, develop schedule, resource plan & budget 2. Analysis – Understand & document in details business needs and processing requirements 3. Design – Design solution based on the requirements 4. Implementation – Build, Test & Install 5. Support – Keep system running The most predictive approach is called the pure waterfall model as it assumes that the various phases of a project can be carried out and completed sequentially.
Once a phase is completed, you cannot go back to it (like going over a waterfall). In practice the pure waterfall approach is not very effective as there are always areas that need further development. There is a modified waterfall model that is more adaptive/predictive. Using this model basically you are saying that there are set phases, but that there may be overlap between them. A benefit of the modified model is efficiency as it allows team members to start phases or do pre-phases without having completed the previous phases. i. e. you may want to design a section of the system while planning because there is sufficient clarity initially. The Newer Adaptive Approaches to the SDLC
The adaptive approach means a development approach in which project activities – including plans & models – are adjusted as the project progresses. One popular technique is called the spiral model. The spiral model is considered the first adaptive approach to system development. For more info on it refer to the wiki entry here… A key concept of the spiral model is the focus on risk, basically you identify the greatest risks first and address these in your first iteration. This may require producing a POC to prove the technology is viable etc. Iteration means that work activities – analysis, design, implementation – are done once. A project may have many iterations depending on its complexity.
With most of the adaptive approaches the emphasis is on tackling the toughest problems first that have the highest risk ranking, then fine tuning the system to accommodate the entire problem scope. ————————————————- Activities of Each SDLC Phase There are several sections of the SDLC Phase, which include… * Project Planning – identify the scope of the system, ensure feasibility & develop a schedule & resource plan * Analysis Activities – understand & document the business needs & processing requirements of the system (discovery & understanding) * Design Activities – design solution based on requirements * Implementation Activities – result in final system being built. Support Activities – keep the system running productively during the time following the initial installation. Project Planning Nothing to important here – read the summary above. Analysis Activities 6 primary activities are considered as part of this phase… 1. Gather Information – learn about the problem domain 2. Define System Requirements 3. Build prototypes for discovery requirements 4. Prioritize requirements 5. Generate & evaluate alternatives 6. Review recommendations with management Design Activities 7 major activities must be completed during this phase… 1. Design & integrate the network 2. Design the application architecture 3. Design the user interfaces 4. Design the system interfaces . Design and integrate the database 6. Prototype for design details 7. Design and integrate the system controls Design activities are closely interrelated and generally are done with substantial overlap. Implementation Activities 5 major activities must be completed during this phase… 1. Construct software components 2. Verify and test 3. Convert data 4. Train users and document the system 5. Install the system Support Activities 3 major activities occur during this phase… 1. Maintain the system 2. Enhance the system 3. Support the users ————————————————- Methodologies, Models, Tools & Techniques Methodologies
A system development methodology provides guidelines to follow for completing every activity in the SDLC, including specific models, tools, and techniques. Because methodology contains instructions about how to use models, tools, and techniques, one must understand what these are… Models A model is a representation of an important aspect of the real world. It is sometimes called an abstraction as it is used to separate out and aspect of particular importance. There are many different models that are used in the SDLC, including planning models such as Gantt charts, or implementation models such UML diagrams. Some models of system components include…. * Flowchart * Data flow diagram * Entity relationship diagram * Structure chart * Use case diagram * Class diagram * Sequence diagram
Some models used to manage the development process include… * Gantt chart * Organizational Hierarchy chart * Financial Analysis Model Tools A tool in software development is software support that helps create models or other components required in the project. They can include really anything, but a few examples would be… * Drawing Programs for Diagrams * Database Applications to store information * IDE for programming * Microsoft project for planning Techniques A technique in system development is a collection of guidelines that help an analyst complete a system development activity or task. Some examples include… * Data-modelling techniques * Software-testing techniques * User-interviewing techniques Relational-database design techniques A methodology includes a collection of techniques that are used to complete activities within each phase of system development. ————————————————- Two Approaches to System Development There are several approaches to system development and in the real world actual implementations of approaches vary from company to company however in this book they have divided it into two groups, the traditional approach and the object orientated approach… The Traditional Approach The traditional includes many variations based on techniques used to develop information systems with structured and modular programming.
The approach is often referred to as the structured system development approach, but has also been refined (which is called the information engineering approach). There are three techniques that make up the Structured System Development approach. They are… 1. Structured Analysis 2. Structured Design 3. Structured Programming These three techniques are often referred to collectively as the Structured Analysis & Design Technique (SADT). Structured Analysis (Modern) is the technique of defining system requirements. This approach requires one to define… * What the system needs to do * What data the system needs to store & use * what input & outputs are needed * How the functions work together as a whole
Initially this was done using DFD (Data Flow Diagrams), which shows the inputs, storage, outputs & processing. Another diagram called the ERD (Entity Relationship Diagram) which is a database modelling method used to produce a type of conceptual scheme of a system. Structured Design is the technique developed for providing some guidelines for deciding what the set of programs should be in a system, what each program should accomplish, and how the programs should be organized. The modules and arrangement of the modules can be shown graphically using a structure chart. There are two main principles of structured design which are… 1. Loosely coupled 2. Highly cohesive
Structured Programming is the technique of creating high quality programs that generate the correct outputs and are easy for other programmers to read. A structured program is one that has one beginning and one ending and each step in the program execution consists of one of three programming constructs 1. A sequence of program statements 2. A decision where one set of statements or another set of statements executes 3. A repetition of a set of statements Another concept related to structured programming is Top-down programming where one module controls sub modules, and those sub modules each have sub-sub modules etc. Some Weaknesses of the Structured Approach Address some but not all of the activities of analysis & design * Makes processes rather than data the central focus Information Engineering Information engineering is a refinement to structured development that begins with overall strategic planning to define all of the information systems that an organization needs to conduct its business. The information engineering approach refines many of the concepts of structured approach into rigorous and comprehensive methodology, thus the book will refer to both these approaches as the traditional approach. The Object Oriented Approach The object oriented approach views systems as a collection of interacting objects that work together to accomplish tasks.
An object is a thing in the computer system that is capable of responding to messages. The object oriented approach covers three main areas… * Object oriented analysis – defines all of the types of objects that do the work in a system * Object oriented design – defines all of the additional types of objects necessary to communicate with various things, refines definitions of each objects so that it can be implemented in a programming language. * Object oriented programming – consists of writing statements in a programming language to define what each type of object will do. A classification or “class” represents a collection of similar objects in a system. Classes can be represented using class diagrams.
The object orientated approach has several benefits including… * It seems natural in many scenarios to specify things as objects * It allows for reuse of objects in other systems Current Trends in Development There are always new approaches coming out on the market. Some examples of these include… * The Unified Process * Extreme Programming * Scrum I will not cover these topics from the book, but it may be worth checking out their definitions in wiki. Tools to Support System Development There are many tools that support system development that help automate the process. Examples of these tools include… * Microsoft Visio (for diagram modelling) * IBM’s rational software Object Oriented Analysis UNISA Studies – Chap 3 Objectives of Chapter 3 Explain the elements of project management and the responsibilities of a project manager * Explain project initiation and the project planning activities of the SDLC * Describe how the scope of the new system is determined * Develop a project schedule using Gantt charts * Develop a cost/benefit analysis and asses the feasibility of a proposed project * Discuss how to staff and launch a project ————————————————- Key Words & Definitions * project management – organizing and directing other people to achieve a planned result within a predetermined schedule and budget * client – the person or group that funds the project oversight committee – clients and key managers who review and direct the project * user – the person or group of people who will use the new system * agile software development – a philosophy of software development that embraces flexibility and agility * weighted scoring – a method to prioritize projects based on criteria with unequal weights * business benefits – the benefits that accrue to the organization; often measured in monetary terms * system scope document – a document containing problem description, business benefits, and system capabilities to help define the scope of a new system * proof of concept – a very preliminary prototype built to illustrate that a solution to a business need is feasible * context diagram – a data flow diagram (DF) showing the scope of a system
* work breakdown structure (WBS) – the hierarchy of phases, activities, and tasks of a project; one method to estimate and schedule the tasks of a project * PERT/CPM chart – a technique for scheduling a project based on individual tasks, or activities * Gantt chart – a bar chart that represents the tasks and activities of the project schedule * critical path – a sequence of tasks that cannot be delayed without causing the project to be completed late * slack time / float – the amount of time a task can be delayed without affecting the project schedule * milestone – a definite completion point in a schedule that is marked by a specific deliverable or event * risk management – the project management area in which the team tries to identify potential trouble spots that could jeopardize the success of the project * cost/benefit analysis – the analysis to compare costs and benefits to see hether investing in the development of a new system will be beneficial * net present value (NPV) – the present value of dollar benefits and costs for an investment such as a new system * payback period – the time period in which the dollar benefits have offset the dollar costs * breakeven point – the point in time at which the dollar benefits have offset the dollar costs * return on investment (ROI) – a measure of the percentage gain from an investment such as a new system. * tangible benefits – benefits that can be measured or estimated in terms of dollars that accrue to the organization * intangible benefits – benefits that accrue to the organization but that cannot be measured quantitatively or estimated accurately ————————————————- Example Questions for the Chapter * List the seven reasons why projects fail * What are three reasons why projects are initiated * Explain how information system project management is similar to project management in general ————————————————- Project Management
Project management is the organizing and directing other people to achieve a planned result within a predetermined schedule and budget. There are many reasons why projects do not fulfil the desired objectives or are only partially successful. They include the following… * Incomplete or changing system requirements * Limited user involvement * Lack of executive support * lack of technical support * Poor project planning (including inadequate risk assessment) * Unclear objectives (including unreasonable expectations) * Lack of required resources Additional studies of successful projects help to highlight some reasons why projects succeed.
They include… * Clear system requirements * Substantial user involvement * Support from upper management * Thorough and detailed project plans * Realistic work schedules and milestones The questions is then asked, how can we improve the project success rate? Companies that have achieved this have attacked the problem from three different angles… 1. Identify best practices in project management & train project their project leaders on these practices 2. They adopt a system development methodology 3. They pay particular attention to factors that influence project success and focus on instituting characteristics of successful projects The Role of a Project Manager The project manager defines and executes project management tasks * The project manager serves as the director or locus of control for the project team and all their activities The following identifies a few of the internal responsibilities… * Identify project tasks and build a work breakdown structure * Develop the project schedule * Recruit and train team members * Assign team members to tasks * Coordinate activities of team members and sub teams * Asses project risks * Monitor and control project deliverables and milestones * Verify the quality of project deliverables Some of the major external responsibilities include the following… * Report the project’s status and progress Establish good working relationships with those who identify the needed system requirements * Work directly with the client and other stakeholders * Identify resource needs and obtain resources Project Management through the SDLC Three major project management processes overlap the SDLC processes… 1. Executing 2. Controlling 3. Closing There are two types of life cycles in the SDLC,
1. Predictive 2. Adaptive With either approach the role of the project manager is slightly different, because these approaches are different, however with either approach the project manager will be involved in all three SLDC processes. Project Management and the Level of Formality Depending on the scope of the project, the level of formality in the project planning may vary * Smaller projects may be less formal, while larger projects may be more formal * Also, whether the project is predictive or adaptive also effects the level of formality In some of the newer agile approaches the level of formality is a lot lower with the emphasis being on things being useful rather than conforming to procedure. Project Management Knowledge Areas There are many professional organizations that focus on project management. One of the these organizations, the PMI, has established a body of knowledge called the PMBOK which has 9 different knowledge areas… 1. Project Scope Management 2. Project Time Management 3. Project Cost Management . Project Quality Management 5. Project Human Resource Management 6. Project Communication Management 7. Project Risk Management 8. Project Procurement Management 9. Project Integration Management ————————————————- Project Initiation and Project Planning Information system development projects are initiated for various reasons, three general driving forces are as follows… 1. To respond to an opportunity 2. To resolve a problem 3. To conform to a directive Some project are initiated to respond to an opportunity. These projects are usually initiated through strategic planning and are called top-down projects.
To prioritize these projects, companies use a technique called a weighted score. A weighted score is a method to prioritize projects based on criteria with unequal weights. Projects are also initiated to solve an immediate business problem. These projects attempt to close the gap between what is required to run the business correctly and what is currently in operation. Projects are also initiated to conform to a directive. For example, legislature by government. Whatever the source of the new project, be sure to carefully evaluate its feasibility before proceeding. Project Planning Activities Both predictive and adaptive projects begin with overall project planning.
The major difference between the two types of projects is the level of detail provided. Predictive projects tend to attempt to plan the entire project upfront while adaptive projects leave much of the detail to be developed during the iteration. The project planning activities of the SDLC consist of the activities required to get the project organized and started. They include the following… * Define the problem * Produce the project schedule * Confirm project feasibility * Staff the project * Launch the project ————————————————- Defining the Problem Carefully defining the problem is one of the most important activities of the project.
The objective is to define precisely the business problem to be solved and thereby determine the scope of the new system. Defining the problem can be divided up into individual tasks, for example the following tasks would be valid… 1. Review the business needs that originally initiated the project 2. Identify at a high level the expected capabilities of the new system 3. Possibly build preliminary prototypes 4. Develop diagrams mapping the flow of data in and out of the system The key question to be answered when completing the problem definition activity is: Do we understand what we are supposed to be working on? ————————————————- Producing the Project Schedule
When producing a project schedule it is important to understand the definitions of two keywords… * Task –is the smallest piece of work that is identified and scheduled * Activity – an activity is made up of a group of related tasks or other smaller activities During project planning it may not be possible to schedule every task in the entire project because it is to early to know all of the tasks that will be necessary, however one of the requirements of project planning is to provide estimates of the time to complete the project and the total cost of salaries. The development of a project schedule is divided into three main steps… 1. Develop a work breakdown structure 2. Build a schedule using a Gantt chart 3.
Develop a resource requirements and the staffing plan A work breakdown structure (WBS) is the hierarchy of phases, activities, and tasks of a project; one method to estimate and schedule the tasks of a project. The for most effective techniques for identifying the tasks of the WBS are… 1. Top-down – identify major activities first and then listing internal tasks 2. Bottom-up – listing all the tasks you can think of and then organizing them later 3. Template – Using a standard template of tasks for projects that are fairly standard 4. Analogy – Finding a similar, or analogous, project that is finished and copying its tasks Usually teams try to use the analogy or template approach first.
When developing a WBS, to help determine if you have the right level of detail you can apply the following guidelines… 1. There should be a way to recognize when the task is complete 2. The definition of the task should be clear enough so that someone can estimate the amount of effort required to complete it 3. As a general rule for software, the effort should take 2 to 10 working days To know more about a Gannt chart see the wiki. ————————————————- Identifying Project Risks and Confirming Project Feasibility Project feasibility analysis is an activity that verifies whether a project can be started and successfully completed.
Generally the following activities are perfomed when confirming project feasibility… * Assess the risk to the project * Determine the organizational and cultural feasibility * Evaluate the technological feasibility * Determine the schedule feasibility * Assess the resource feasibility * Determine the economic feasibility Assess the risk to the project During the project initiation the primary objective of risk management is to identify potential risks and assess their negative impact. One of the best ways to do this is to have a brainstorming session which includes key project members. Determine the organizational and cultural feasibility Evaluate & identify organizational & cultural issues that pose potential risks for the new system.
These could include… * current low level of computer competency * substantial computer phobia * perceived loss of control by staff or management * potential shifting of political and organizational power due to the new system * fear of change of job responsibilities * fear of loss of employment due to increased automation * reversal of long standing work procedures Evaluate the technological feasibility * assess carefully the proposed technological requirements & available expertise Determine the schedule feasibility * the project team should build the schedule without any preconceived notion of required completion dates. * compare the schedule to key times – i. e. or a university admissions system, identify when admissions start so that one knows when the system must be implemented by. Assess the resource feasibility Be aware of the resource feasibility of the project. This includes Economic Feasibility. Economic feasibility consists of two tests… 1. Is the anticipated value of the benefits greater than projected costs of development? 2. Does the organization have adequate cash flow to fund the project during the development period? For a full description on feasibility refer to the chapter in the book. Completing the Feasibility Analysis For a project to be viable it should pass all of the feasibility tests.
If it is not feasible in one area, either adjustments need to be made or the project cancelled. ————————————————- Staffing & Launching the Project The staffing activity consists of 5 tasks… 1. Develop a resource plan for the project 2. Identify and request specific technical staff 3. Identify and request specific user staff 4. Organize the project team into workgroups 5. Conduct preliminary training and team-building exercises Structured System Analysis & Design UNISA Studies – Chap 4 Objectives of Chapter 4 * Describe the activities of system analysis. * Explain the difference between functional and non-functional system requirements. Describe three types of models and reasons for creating models * Identify and understand the different types of users who will be involved in investigating system requirements * Determine the kind of information that is required to model system requirements * Determine system requirements through review of documentation, interviews, observation, prototypes, questionnaires, joint application design sessions, and vendor research. * Discuss the need for validation of system requirements to ensure accuracy and completeness and the use of a structured walkthrough. ————————————————- Key Words & Definitions logical model – any model that shows what the system is required to do without committing to any one technology * physical model – any model that shows how the system will be actually implemented * system requirements – specifications that define the functions to be provided by a system * functional requirements – a system requirement that describes an activity or process that the system must perform * non-functional requirement – characteristics of the system other than activities it must perform or support, such as technology, performance, usability, reliability, and security * technical requirement – a system requirement that describes an operational characteristic related to an organization’s environment, hardware, and software * performance requirement – a system requirement that describes an operational characteristic related to workload measures, such as throughput and response time. usability requirement – a system requirement that describes an operational characteristic related to users, such as the user interface, work procedures, online help, and documentation. * reliability requirement – a system requirement that describes the dependability of a system, such as how it handles service outages, incorrect processing, and error detection and recovery. * security requirement – a system requirement that describes user access to certain functions and the conditions under which access is granted. * Mathematical model – a series of formulas that describe technical aspects of a system.
* Descriptive model – narrative memos, reports, or lists that describe some aspect of a system. Graphical model – diagrams and schematic representations of some aspect of a system. * Stakeholders – all the people who have an interest in the success of a new system. * Transaction – a single occurrence of a piece of work or an activity done in an organization. * workflow – a sequence of steps to process a business transaction. * activity diagram – a type of workflow that describes the user activities and their sequential flow. * synchronization bar – a symbol in an activity diagram to control splitting or uniting of sequential paths. * swimlane – a rectangular area on an activity diagram representing the activities of a single agent. * prototype – a preliminary working model of a larger system. mock-up – an example of a final product that is for viewing only and is not executable * closed-ended questions – questions that have a simple, definitive answer. * open-ended questions – questions that require discussion and do not necessarily have a simple, short answer. * joint application design (JAD) – a technique to define requirements or design a system in a single session by having all necessary people participate. * group support system (GSS) – a computer system that enables multiple people to participate with comments at the same time, each from their own computer. * structured walkthrough – a review of the findings from your investigation and of the models built based on those findings. ————————————————- Analysis Activities in More Detail
There are six activities that need to be covered in analysis. They are… 1. Gather Information 2. Define System Requirements 3. Prioritize Requirements 4. Prototype for Feasibility & Discovery 5. Generate and Evaluate Alternatives 6. Review Recommendations with management Keep in mind that these six activities are usually done almost simultaneously. For instance, one might be defining system requirements while gathering information, etc. Here are the top key questions the book outlines for each activity… Analysis Activity| Key Questions| Gather Information| Do we have all of the information (and insight) we need to define what the system must do? Define System Requirements| What (in detail) do we need the system to do? | Prioritize Requirements| What are the most important things the system must do? | Prototype for Feasibility & Discovery| Have we proven that the technology proposed can do what we think we need it to do? Have we built some prototypes to ensure the users fully understand the potential of what the new system can do? | Generate & Evaluate Alternatives| What is the best way to create the system? | Review Recommendations with Management| Should we continue with the design and implement the system we propose? | ————————————————- Functional and Non-functional System Requirements
System requirements are all the capabilities and constraints that the new system must meet. The system requirements are typically divided into functional and non functional requirements. Functional requirements * Functional requirements are the activities that the system must perform. * They are what the business intends on using the system for. * They are based on the procedures and rules that the organization uses. See wiki for more info on functional requirements. Non-functional requirements * Non-functional requirements are characteristics of the system other than activities it must perform or support. There are many different types of non-functional requirements.
Some examples of the include: * technical requirement * performance requirement * usability requirement * reliability requirement * security requirement Have a look at the key definitions at the top of the blog for an explanation of the above requirements. See wiki for more info on non-functional requirements. ————————————————- Models and Modelling The Purpose of Models Models help discover how a system should work… the following are the major reasons why models are used for system development. * Learning from the modelling process * Reducing complexity by abstraction * Remembering all of the details * Communicating with other development team members Communicating with a variety of users and stakeholders * Documenting what was done for future maintenance/enhancement Types of Model There are three main types of models. 1. Mathematical Models 2. Descriptive Models 3. Graphical Models Mathematical Models * A series of formula to describe technical aspects of a system * Usually models technical requirements Descriptive Models * Narrative memos, reports, or lists * Sometimes descriptive models are converted to graphical models for better visualization * A form of descriptive modelling is pseudo code – or structured English to describe an algorithm Graphical Models * Probably the most useful type of model Includes diagrams and schematic representations of some aspect of the system * UML is an example of a graphical model. ————————————————- Stakeholder –
The Source of System Requirements Stakeholders are all the people who have an interest in the successful implementation of the system. They can generally be categorized into one of three groups. 1. Users – people who actually use the system 2. Clients – people who pay for the system 3. Technical Staff – people who support the system User Stakeholders Examples of users include… * Business Users – people who capture data – i. e. generate an order * Information Users – people who view data but cannot change it – i. e. omeone viewing the progress of an order * Management Users – people who monitor the performance of the business and need dashboards etc. * Executive Users – people who are concerned with the overall aspect of the business/system * External Users – for example, customers who order from home online Client Stakeholders * Client stakeholders are the people paying/funding the development of the system * Sometimes the client stakeholder is also the executive user, however sometimes it is a third party group that funds the project. Technical Stakeholders * The people who maintain the system. * Sometimes a technical stakeholder will form part of the development system. ————————————————- Techniques for Information Gathering
Development of system requirements was initially a four step process… 1. Identify the physical processes and activities of the existing system 2. Extract the logical business function that was inherit in each existing physical process 3. Develop the logical business functions for the approach to be used in the new system 4. Define the physical processing requirements of the new system A major disadvantage of this approach was the time it took to complete. Also, often system analysts would simply automate the existing procedures without any innovation. Avoid “analysis paralysis: by focussing on the new system requirements from the beginning.
Now days, analysis focuses on certain themes and uses various techniques to develop the logical model of the system. This is done by focussing on question themes. Question Themes * What are the Business Processes? * How is the Business Process Performed? * What Information is Required? The processes to answer the above questions can usually be achieved by doing the following… * Reviewing existing reports, forms & procedure descriptions * Conduct Interview & Discussion with Users * Observing and documenting business processes * Building prototypes * Distributing & collecting questionnaires * Conducting Joint Application Design Sessions (JAD) * Research Vendor Solutions
Reviewing existing reports, forms & procedure descriptions * Study best practices in Industry Journals * Study existing reports & forms used in the organization and understand the data that is being captured and why it is important. Conduct Interview & Discussion with Users Try and have at least two team members attend interviews so that they can verify their results Things to do before the interview * Establish the objective for the interview * Determine correct user’s to be involved * Determine project team members to participate * Build a list of questions and issues to be discussed * Review related documents and materials * Set time & location Inform all participants of objective, time & locations Things to do during the interview * Dress appropriately * Arrive on time * Look for exception and error conditions * Probe for details * Take thorough notes * Identify and document unanswered items or open questions Things to do after the interview * Review notes for accuracy, completeness and understanding * Transfer information to appropriate models and documents * Identify areas needing further clarification * Send thank-you notes if appropriate Maintain an open-items list for unresolved problems and questions that came up in the interviews Observing and Documenting Business Processes
* Observe business processes in action Document Workflows with Activity Diagrams Building Prototypes There are many different names for prototypes including… * thowaway prototype * discovery prototype – used for a single discovery objective and then discarded after the concept has been tested. * design prototype * evolving prototype – are prototypes that grow and change and may eventually even be used as the final, live system Effective prototypes usually have the following attributes. * Operative – should be a working model and display look & feel * Focussed – should test a specific concept and focussed on its objective * Quick – Should not take to long to develop Distributing & Collecting Questionnaires Questionnaires include closed & open ended questions. * Limit the number of open ended questions (rather use them in interviews) Conducting Joint Application Development See wiki for more info on JAD. The following people & groups may be involved in a JAD session… * JAD Session Leader * Users * Technical Staff * Project Team Members One of the dangers of JAD is the risk involved in expediting decisions because the objective of a JAD session is to come to a conclusion quickly on policy decisions & requirements, sometimes decisions are not optimal however JAD sessions have been largely successful in reducing project development efforts & shortening the schedule. Research Vendor Solutions There may already be a solution on the market that solves the existing problem
* The danger is that an off the shelf solution may not solve all of the problems so proper investigation is necessary Try and get the following about a product before buying a solution * Technical Specifications * Demo or Trial of the System * References of Existing Clients who use the system * An on-site visit * Printout of screens & reports ————————————————- Validating the Requirements It is important to validate system requirements before development begins as it can be very expensive to change the system requirements once programming has commenced. There are various techniques to validate information systems, ne such technique is called a structured walkthrough whereby the analyst run through the system/sub system step by step and is reviewed by a panel. (see wiki for more info) In a structured walkthrough, one should have a nonparticipant act as a “librarian” to record all errors, comments, and suggestions. Once a walkthrough ahs been completed it is important to have a follow-up which is any corrections are made. If there are major issues an additional walkthrough with the amendments may be required Structured System Analysis & Design UNISA Studies – Chap 5 Objectives of Chapter 5 * Understand why identifying use cases is the key to defining functional requirements * Use three techniques for identifying use cases Write brief, intermediate, and fully developed use case descriptions * Explain how the concept of things in the problem domain also define requirements * Identify and analyze data entities and domain cases needed in the system * Read, interpret, and create an entity-relationship diagram * Read, interpret, and create a domain model class diagram ————————————————- Key Word & Definitions * use case – an activity the system performs * user goal technique – an approach for identifying use cases in which an analyst talks to all users to get them to describe their goals in using the system
* CRUD techniques – an approach in which an analyst looks at each type of data and includes use cases that create the data, read or report on the data, update the data, and delete the data. elementary business process (EBP) – a task that is performed by one person, in one place, in response to a business event; it adds measurable business value and leaves the system and its data in a consistent state. * event – an occurrence at a specific time and place that can be described and is worth remembering * event decomposition – an analysis technique that focuses on identifying the events to which a system must respond and then determining how the system must respond. * external event – an event that occurs outside the system, usually by an external agent or actor. * temporal event – an event that occurs as a result of reaching a point in time. state event – an event that occurs when something happens inside the system that triggers the need for processing * system controls – check or safety procedures put in place to protect the integrity of the system * perfect technology assumption – the assumption that events should be included during analysis only if the system would be required to respond under perfect conditions. * event table – a catalogue of use cases that lists events in rows and key pieces of information about each event in columns. * trigger – a signal that tells the system that an event has occurred, either the arrival of data needing processing or a point in time. source – an external agent or actor that supplies data to the system * response – an output, produced by the system, that goes to a destination * destination – an external agent or actor that receives data from the system * use case description – a description that lists the processing details for a use case * actor – in UML diagrams, a person who uses the system * scenario or use case instance – a unique set of internal activities within use case that represents a unique path through the use case * preconditions – conditions that must be true before a use case begins * post conditions – conditions that must be true upon completion of the use case * relationship – a naturally occurring association among specific things, such as “an order is placed by a customer and an employee works in a department”
* cardinality – the number of associations that occur among specific things, such as a customer places many orders and an employee works in one department. * multiplicity – a synonym for cardinality binary relationships – relationships between two different types of things such as a customer and an order * unary relationships – a relationship among two things of the same type, such as one person being married to another person * ternary relationship – a relationship among three different types of things * n-ary relationship – a relationship among n different types of things * attribute – one piece of specific information about a thing * identifier (key) – an attribute that uniquely identifies a thing * compound attribute – an attribute that contains a collection of related attributes * data entities – the things about which the system needs to store information in the traditional approach to information systems * associative entity – a data entity that represents a many-to-many relationship between two other data entities * generalization / specialization hierarchies – hierarchies that structure or rank classes from the more general super class to the more specialized subclasses; sometimes called inheritance hierarchies. inheritance – a concept that allows subclasses to share characteristics of their super classes * whole-part hierarchies – hierarchies that structure classes according to their associated components * aggregation – whole-part relationship between an object and its parts * composition – whole-part relationship in which the parts cannot be dissociated from the object ————————————————- User Goals, Events, & Use Cases (See Wiki on Use Cases for more info) Use cases are used in almost all modern system analysis approaches. A use case is an activity the system performs, usually in response to a request by a user.
Several techniques are recommended for identifying use cases including… * User Goal Technique – This is an approach for identifying use cases in which an analyst talks to all users to get them to describe their goals in using the system. * CRUD Technique – This an approach in which an analyst looks at each type of data and includes use cases that create the data, read or report on the data, update the data, and delete the data * Event Decomposition Technique – This is the most comprehensive technique for identifying use cases and focuses on identifying the events to which a system must respond and then determining how the system must respond.
It is important with use cases to identify the appropriate level of detail, you do not want to be to broad, or to narrow. One way to do this is to define the EBP (Elementary Business Process). Basically, an EBP is a process where no major time gap occurs during the process – i. e. it may seem seamless. Event Decomposition Technique * identify the events to which a system must respond * determine how the system must respond * focus on events Types of Events There are three main types of events in a system… 1. External Event – an event that occurs outside the system, usually by an external agent or actor. 2. Temporal Event – an event that occurs as a result of reaching a point in time (time based event) 3.
State Event – an event that occurs when something happens inside the system that triggers the need for processing Identifying Events It is not always easy to define the events that affect a system. The following need to be taken into consideration. * Events vs. Prior Conditions & Response – is this actually an event or part of a prior condition? Try and use the EBP principle. * The Sequence of Events : Tracing a Transactions Life Cycle – sometimes useful to trace all events that will occur with an actor. * Technology Dependent Events & System Controls – assume the “perfect technology assumption”. These events should not form part of the initial use cases as they are technology dependant – i. e. logging in to a system, etc. Event Table
An event table is a catalogue of use cases that lists events in rows and key pieces of information about each event in columns. An event table includes row and columns representing events and their details, respectively. An example of an event table is shown below… Event| Trigger| Source| Use Case| Response| Destination| Customer wants to check item availability| Item Inquiry| Customer| Look up item availability| Item Availability Details| Customer| Use an event table as a catalogue of information about the use cases that make up the functional requirements of the system Each column in the event table represent a section… * trigger – a signal that tells the system that an event has occurred, either the arrival of data needing processing or a point in time. source – an external agent or actor that supplies data to the system * response – an output, produced by the system, that goes to a destination * destination – an external agent or actor that receives data from the system ————————————————- Use Case Descriptions A list of use cases and an event table provide an overview of all the use cases for a system. Detailed information about each use case is described with a use case description. In UML, an actor is a person. An actor is always outside the automation boundary of the system but may be part of the manual portion of the system. There are three levels of use case descriptions… 1. Brief Description 2. Intermediate Description 3. Fully Developed Description Brief Description * Used for very simple use cases * Usually it is changed to a intermediate description or a fully developed description Intermediate Description
Below is an example of a template layout for a intermediate description… Title of the Use Case| Main Flow * Step by Step descriptions of the flow | Exception Conditions | | Fully Developed Description * The most formal description * Example of description listed below… Use Case Name| | Scenario| | Triggering Event| | Brief Description| | Actors| | Related Use Cases| | Preconditions| | Post conditions| | Flow of Activities| Actor| System| | | | Exception Conditions| | | | Preconditions and post conditions are critical to understanding the processing done for a use case. ————————————————- “Things” in the Problem Domain
In the traditional approach, the “things” make up the data that is stored. The type of data that is stored is key to the system requirements. In the object orientated approach, the “things” make up the objects that are mapped. Whether you use the traditional or object oriented approach, identifying the “things” is a key initial step. Types of Things An analyst can identify the types of things by thinking about each event in the event table and asking questions. There are several procedures that can assist an analyst in this process. Outlined below is one such procedure… 1. Use the event table and information about each event and identify all of the nouns. 2.
Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed 3. Refine the list and record assumptions or issues to explore. Relationships Among Things Once you have identified the “things”, you should identify the relationship between them. A relationship is a naturally occurring association among specific things, such as “an order is placed by a customer and an employee works in a department”. It is important to note that relationships between things apply in two directions – i. e. a customer orders a products, products have been ordered by a specific customer.
It is important to also understand the cardinality that exists between objects. Cardinality is the number of associations that occur among specific things, such as a customer places many orders and an employee works in one department. Sometimes this can be called multiplicity. (see wiki for more on cardinality) It is important not just to understand the cardinality, but also the range of possible values. i. e. A particular customer might not ever place an order, but if he wanted to he could place many orders. (range is the minimum and maximum cardinality). There are several different types of relationships… outlined below are some of the major ones… ? binary relationships – relationships etween two different types of things such as a customer and an order ? unary relationships – a relationship among two things of the same type, such as one person being married to another person ? ternary relationship – a relationship among three different types of things ? n-ary relationship – a relationship among n different types of things Initially focus on identifying each “thing” in the problem domain, but also be sure to focus on associations/relationships among them, which are often just as important to the system users.
Attributes of Things An attribute is one piece of specific information about a thing. In . Net we usually call these properties of objects. i. e. he Name of a Person would be an attribute. Some attributes are key identifiers which means that the attribute uniquely identifies the “thing”. You can also get compound attributes – which is an attribute that contains a collection of related attributes – i. e. Full Name is a compound attribute of First Name & Last Name. ————————————————- The Entity-Relationship Diagram Data entities are the things about which the system needs to store information in the traditional approach to information systems. The model used to define the data storage requirements with the traditional approach is called the entity-relationship diagram (ERD). For more information on ERD diagrams see the wiki) An important aspect of an entity diagram is an associative entity which is a data entity that represents a many-to-many relationship between two other data entities. Several refinements are done to ERD during the design process. One such refinement is called normalization (see wiki for more info). ————————————————- The Domain Model Class Diagram The domain model class diagram (See wiki for more info) is a type of UML class diagram shows the things in the users work domain. The book covers the notation for this type of UML diagram however the summary will not go into any depth on this.
The section also covers generalization/specialization of classes. A generalization / specialization hierarchy is one in which one can structure or rank classes from the more general super class to the more specialized subclasses; sometimes called inheritance hierarchies. i. e. A Vehicle Class can have specialization sub classes of Cars or Trucks. Another way that people structure information about things is by defining them in terms of their parts. This is called whole-part hierarchies. Whole-part hierarchies are hierarchies that structure classes according to their associated components. There are two types of whole part hierarchies… 1. Aggregation 2. 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 a form of association that is even stronger than aggregation, where the parts once associated, can no longer exist separately. (See Page 191 of the book for graphical examples). Whole-part hierarchies serve mainly to allow the analyst to express subtle distinctions about associations among classes. As with any association relationship, multiplicity can apply such as when a computer has one or more disk storage devices. Composition – whole-part relationship in which the parts cannot be dissociated from the object
Structured System Analysis & Design UNISA Studies – Chap 6 Objectives of Chapter 6 * Explain how the traditional approach and the object oriented approach differ when modelling the details of a use case. * List the components of a traditional system and the symbols representing them on a data flow diagram. * Describe how data flow diagrams can show the system at various levels of abstraction * Develop data flow diagrams, data element definitions, data store definitions, and process descriptions * Develop tables to show the distribution of processing and data access across system locations ————————————————- Key Word & Definitions data flow diagram (DFD) – a diagram that represents system requirements as processes, external agents, data flows, and data stores * external agent – a person or organization outside the system boundary, that supplies data inputs or accepts data outputs * process – a symbol on a DFD that represents an algorithm or procedure by which data inputs are transformed into data outputs * data flow – an arrow on a DFD that represents data movement among processes, data stores, and external agents * data store – a place where data is held pending future access by one or more processes * level of abstraction – any modelling technique that break the system into a hierarchical set of increasingly more detailed models * context diagram – a DFD that summarizes all processing activity within the system in a single process symbol * DFD fragment – a DFD that represents the system response to one event within a single process symbol * event-partitioned system model, or diagram 0 – a DFD that models system requirements using a single process for each event in a system or subsystem * information overload – difficulty in understanding what occurs when a reader receives too much information at one time * rule of 7+-2 – the rule of model design that limits the number of model components or connections among components to no more than nine * minimization of interfaces – a principle of model design that seeks simplicity by limiting the number of connections among model components * balancing – equivalence of data content between data flows entering and leaving a process and data flows entering and leaving a process decomposition DFD * black hole – a process of data store with a data input that is never used to produce a data output * miracle – a process or data store with a data element that is created out of nothing
* Structured English – a method of writing process specifications that combines structured programming techniques with narrative English * decision table – a tabular representation of processing logic containing decision variables, decision variable values, and actions or formulas * decision tree – a graphical description of process logic that uses lines organized like branches of a tree * data flow definition – a textual description of a data flow’s content and internal structure * data dictionary – a repository for efinitions of data flows, data elements, and data stores * location diagram – a diagram or map that identifies all of the processing locations of a system * activity location matrix – a table that describes the relationship between processes and the locations in which they are performed ————————————————- Traditional & Object-Oriented Views of Activities/Use Cases Traditional approach * views system as a collection of processes * contains instructions that are typically sequential * involves processes, stored data, inputs & outputs, processing models OO Approach * views system as a collection of interacting objects * objects are based on things in the problem domain objects are capable of behaviours (methods) that allow them to interact with each other * no conventional computer processes or data files per se * includes models that show objects, their behaviour, and their interactions with other objects ————————————————- Data Flow Diagrams (See wiki for more info) * Data flow diagram is the most commonly used process model. * It is a graphical system model that shows all of the main requirements for an information system in one diagram. * It is easy to read. There are only five symbols to learn in a DFD 1. external agent (square) 2. process (rectangle with rounded corners) 3. data flows (lines with arrows) 4. real-time link – communication back and forth between external agents. 5. data store (flat open ended rectangle) An example of a basic DFD using these elements is shown below…
When employing the traditional approach, identify use cases and then model the details of each use case with a data flow diagram fragment DFD’s & Entity Diagrams The DFD integrates processing triggered by events with the data entities modelled using the ERD. The picture below summarizes the correspondence among components of the DFD, events described in the event table and the entities defined in the ERD. Data Flow Diagrams & Levels of Abstraction * DFD’s can show either higher level or lower level vies of a system. * A context diagram is a DFD that describes the most abstract view of a system – it summarizes all processing activity within the system in a single process symbol. The topmost DFD is the context diagram. A context diagram… * clearly shows the system boundary * does not usually show data stores because all of the system’s data stores are considered within the system scope. * usually created in parallel with the event table External agents that supply or receive data from the system are outside the system scope, everything else is in the system scope and would be represented as one or more processes. A DFD fragment… * is a DFD that represents the system response to one event within a single process symbol * is a self contained model showing how the system respond to a single event * usually created one at a time
A event-partitioned system model, or diagram 0… * a DFD that models system requirements using a single process for each event in a system or subsystem * used primarily as a presentation tool * summarises an entire system or subsystem in greater detail than the context diagram * diagram is often complex and unwieldy Physical & Logical DFDs A DFD can be a… 1. physical system model, 2. or a logical system model, 3. or a blend of the two. If a DFD is a logical system model it assumes that the system might be implemented with any technology. If a DFD is a physical model one or more assumptions about the technology will be embedded in the DFD.
A number of elements indicate assumptions about implementation technology… * Technology-specific processes * Actor-specific process names * Technology- or actor-specific process orders * Redundant processes, data flows, and files If it is a logical system, it will make an assumption of perfect technology – meaning there would be no need to put in redundancy – i. e. capturing data incorrectly. Analysts should avoid creating physical DFD’s during all analysis activities, except when generating alternatives. Evaluating DFD Quality High quality DFD’s are… * readable * internally consistent * accurately represent system requirements * have minimized complexity Over complex models lead to information overload.
Information overload is when you have difficulty in understanding what occurs or when a reader receives too much information at one time. To avoid information overload we have the 7+-2 rule. The rule of 7+-2 is the rule that limits the number of model components or connections among components to no more than nine. Minimization of interfaces is directly related to the 7+-2 rule and is the principle of model design that seeks simplicity by limiting the number of connections among model components. Ensuring Data Flow Consistency Look for the following things in a DFD… * Differences in data flow content between process and its process decomposition. * Data outflows without corresponding data inflows. * Data inflows without corresponding data outflows.
The following words denote the above items one should look out for… * balancing – equivalence of data content between data flows entering and leaving a process and data flows entering and leaving a process decomposition DFD * black hole – a process of data store with a data input that is never used to produce a data output * miracle – a process or data store with a data element that is created out of nothing How can black holes & miracles be detected… * Sometimes they can be detected by simply examining the DFD’s for consistency. * In some cases close examination of the data dictionary or process descriptions is also required. * Ensuring data flow consistency is a straightforward but tedious process, fortunately most analysis tools automatically perform consistency checks. ————————————————-
Documentation of DFD Components In the traditional approach, DFD’s show all three types of internal system components on one diagram… 1. Processes 2. Data Flows 3. Data Stores Process Descriptions Each process of a DFD must be defined formally. There are several options for process definition, they include… * Process Decomposition (Explained in previous chapter) * Structured English * Decision Tables * Decision Trees Each type of process is suited to a particular type of DFD process, i. e. a Structured English process might be well suited to record customer information, while a decision tree process might be a bad choice to represent this process.
Structured English is a method of writing process specifications that combines structured programming techniques with narrative English. See the example below… Decision table is a tabular representation of processing logic containing decision variables, decision variable values, and actions or formulas. See the example below… Decision tree is a graphical description of process logic that uses lines organized like branches of a tree. See the example below… Functional requirements documentation for the traditional approach includes 1. an ERD with attributes 2. the set of DFD’s (context DFD, DFD Fragments, and any needed detailed DFD’s 3. process descriptions 4. ata flow definitions, data store definitions & data element definitions A data flow definition is a textual description of a data flow’s content and internal structure. Data element definitions describe a data type, such as a string or integer. Each element should be described to indicate specifically what it represents. Analysts need to maintain a central store of all these definitions as a project reference and to ensure consistency. A data dictionary is a repository for definitions of data flows, data stores, and data elements. DFD Summary A DFD will contain * Data Flow Diagrams * Process Definitions * Data Definitions * ERD Diagrams ————————————————- Locations & Communication through Networks
Because structured systems analysis concentrates on logical modelling, physical issues such as processing locations and networks are sometimes ignored during analysis. However a great deal of information about process, data, and user distribution is needed during the early stages of design. Examples include… * Number of locations of users * Processing and data access requirements of users at specific locations * Volume and timing of processing and data access requests Gathering location information during analysis enables analysts to make better decisions during the last two analysis activities… * Generate & Evaluate Alternatives * Review Recommendations with Management
There are a few steps involved in gathering location information, they are outlined below… 1. Generate a location diagram 2. Generate an activity matrix based on the location diagram Object Oriented Analysis UNISA Studies – Chap 7 Objectives of Chapter 7 * Understand the models and processes of defining object-oriented requirements * Develop use case diagrams and activity diagrams * Develop system sequence diagrams * Develop state machine diagrams to model object behaviour * Explain how use case descriptions and UML diagrams work together to define functional requirements for the object oriented approach ————————————————- Key Words & Definitions use case model – a collection of models that can be used to capture system requirements based on use cases with the object-oriented approach * use case diagram – a diagram to show the various user roles and how those roles use the system * system sequence diagram – a diagram showing the sequence of messages between an external actor and the system during a use case or scenario * message – the communication between objects within a use case * domain model – a model that describes classes of objects and their states * state machine diagram – a diagram showing the life of an object in states and transitions * package – a symbol used to denote a group of similar elements * interaction diagram – either a communication diagram or a sequence diagram that shows the interactions between objects * lifeline, or object lifeline – the vertical line under an object on a sequence diagram to show the passage of time for the object * true/false condition – part of a message between objects that is evaluated prior to transmission to determine whether the message can be sent * state – a ondition during an object’s life when it satisfies some criterion, performs some actions, or waits for an event * transition – the movement of an object from one state to another state * pseudo state – the starting point of a state machine diagram, indicated by a black dot * destination state – for a particular transition, the state to which an object moves after the completion of a transition * origin state for a particular transition – the original state of an object from which the transition occurs * message event – the trigger for a transition, which causes the object to leave the origin state * guard condition – a true/false test to see whether a transition can fire * action expression – a description of the activities performed as part of a transition * concurrency, or concurrent state – the condition of being in more than one state at a time * path – a sequential set of connected states and transitions * composite state – a state containing other states and transitions ————————————————- Example Questions for the Chapter * What is UML? What type of modelling is it used for? What is the difference between a use case description and an activity diagram? * What are the steps required to develop a system sequence diagram? ————————————————- Object Oriented Requirements System development starts with the identification of events that trigger elementary business processes called use cases. The object oriented approach is a “divide and conquer” approach. The use case model is a collection of models that can be used to capture system requirements based on use cases with the object-oriented approach. It includes… * use case diagrams * use case descriptions * activity diagrams * system sequence diagrams
The use case model is a collection of models that can be used to capture system requirements based on use cases with the object-oriented approach The use case diagram is a diagram to show the various user roles and how those roles use the system The system sequence diagram is a diagram showing the sequence of messages between an external actor and the system during a use case or scenario ————————————————- The System Activities – A Use/Case Scenario View The objective of the use case model is to identify and define all of the elementary business processes that the system must support. There are two levels that use cases are defined… 1.
Overview Level – event table & use case diagrams 2. Detailed Level – use case descriptions, activity diagrams, system sequence diagarm Use Cases & Actors A use case is an activity the system carries out usually in response to a request by a user of the system. Implied in all use cases is a person (actor) who uses the system. An actor is always outside the automation boundary of the system, but may be part of the manual portion of the system thus an actor is not always the same as the source of the event in the event table. A source of an event is the initiating person who supplied the data and is usually external to the system (including the manual system).
Be sure that actors have direct contact with the automated system. The Use Case Diagram The diagram below shows how a use case is documented. The use case itself is symbolized by an oval with the name of the use case inside. A use case diagram is a graphical model that summarizes the information about the actors and use cases. Automation Boundary A rectangle is used to indicate an actor that is not a person. In the diagram below the Inventor System is indicated as an actor. 0 Use Case Diagram compared with the Event Table The event table & use case diagram contain much of the same information. The event table is really a catalogue of information about all the use cases.
Some differences do exist between the use case diagram and the event table… * Event table focuses on the business process while an use case diagram emphasis the automated system. * Use cases often overlook temporal & state events Developing a Use Case Diagram If there is an event table, then the analyst will use the event table to generate use case diagrams. If there is no event table, the other starting point is to identify the actors & the elementary business processes with the user goal technique. For this to be feasible you need to make the system boundary an automated system so that the actors identified actually contact the system and you must assume perfect technology.
Once this is done you can generate the use case diagrams using the following two step process… 1. Identify actors of the system – identify the specific roles each person plays 2. Develop the list of goals those roles have in the use of the automated system – a goal is a task performed by an actor to accomplish a business function that adds value to the business. Activity Diagrams for Describing Use Cases Activity diagrams are an effective technique to document the flow of activities for each use case scenario. An activity diagram can be used to support any level of use case descriptions. Early termination of the workflow can be indicated. Activity diagrams are also helpful in developing system sequence diagrams. ———————————————— Identifying Inputs & Outputs – The System Sequence Diagram An SSD Diagram is used to describe the flow of information into and out of the automated system. A System Sequence Diagram is a diagram showing the sequence of messages between an external actor and the system during a use case or scenario An SSD is a type of interaction diagram. Often the word interaction & message are used interchangeably. SSD Notation The emphasis in an SSD is on how the actor interacts with the system by entering data and receiving output data. In an SSD the only object included is one representing the entire system.
A lifeline, or object lifeline is the vertical line under an object on a sequence diagram to show the passage of time for the object Develop SSD’s carefully and correctly. They become critical components for detailed design and user interface design. Developing a System Sequence Diagram A SSD is normally used in conjunction with the use case descriptions to help document the details of a single use case scenario within a use case. To develop a SSD you will either need a fully developed description of a use case or activity diagrams. An SSD will provide the explicit identification of inputs and outputs. The development of an SSD based on an activity diagram can be divided into four steps… 1. Identify the input messages 2.
Describe the message from the external actor to the system using the message notation described earlier 3. Identify and add any special conditions on the input messages, including iteration and true/false conditions 4. Identify and add the output return messages. For a detailed explanation of this process see pages 256 – 260 of the textbook. ————————————————- Identifying Object Behaviour – The State Machine Diagram A state is a condition during an object’s life when it satisfies some criterion, performs some actions, or waits for an event. States are described as semi permanent conditions because external events can interrupt a state and cause the object to go to a new state.
An object remains in a state until some event causes it to move to another state (this is called transition). Transition is the movement of an object from one state to another state. Pseudo state is the starting point of a state machine diagram, indicated by a black dot (see diagram below). Destination state for a particular transition is the state to which an object moves after the completion of a transition. The origin state for a particular transition is the original state of an object from which the transition occurs. The transition name is the name of a message event that triggers the transition and causes the object to leave the origin state. A message event is the trigger for a transition, which causes the object to leave the origin state.
The guard condition is a qualifier or test on the transition and is simply a true/false test to see whether a transition can fire The action expression is a procedural expression that executes when the transition fires. In other words it is a description of the activities performed as part of a transition. Composite States & Concurrency A composite state is a state containing other states and transitions. It means an object is in more than one state at the same time. A composite state represents a higher level of abstraction and can contain nested states and transition paths. Rules for Developing State Machine Diagrams State machine diagram development follows a set of rules. Below is a list of steps that will help one develop state machine diagrams… 1.
Review the class diagram and select the classes that will require state machine diagrams 2. For each selected class in the group, make a list of all the status conditions one can identify 3. Begin building state machine diagram fragments by identifying the transitions that cause an object to leave the identified state 4. Sequence these state transition combinations in the correct order 5. Review the paths and look for independent, concurrent paths 6. Expand each transition with the appropriate message event, guard condition, and action expression 7. Review and test each state machine diagram Object Oriented Analysis UNISA Studies – Chap 8 Objectives of Chapter 8 Prioritize the system requirements based on the desired scope and level of automation for the new system * Describe the strategic decisions that integrate the application deployment environment and the design approach for the new system * Determine alternative approaches for system implementation * Evaluate and select an implementation approach based on the needs and resources of the organization * Describe key elements of a request for proposal (RFP) and evaluate vendors proposals for outsourced alternatives * Develop a professional presentation of findings to management. ————————————————- Key Words & Definitions * application deployment environment – the configuration of computer equipment, system software, and networks for the new system. development environment – the programming languages, CASE tools, and other software used to develop application software * facilities management – the outsourcing of all data processing and information technology to outside vendor * packaged software – software that is already built and can be purchased as a package * turnkey system – a complete system solution, including software and hardware, that can be turned over to the purchasing organization * request for proposal (RFP) – a formal document, containing details on the system requirements, sent to vendors to request that they bid on supplying hardware, software, and/or support services * benchmark – an evaluation of a system against some standard ————————————————- Example Questions for the Chapter * What is meant by application deployment environment? Why is it important in the consideration of a developmental approach? * Explain the fundamentals of facilities management * What is meant by ERP? How does an ERP approach affect acquiring a new solution? ————————————————- Deciding on Scope & Level of Automation
Prioritizing requirements includes tasks to define both the scope and the level of automation for the system. Controlling a Projects Scope A common problem with development projects is scope creep. One way to reduce scope creep is to formalize the process to identify, categorize, and prioritize the functions that will be included within the system. The team needs to decide which functions are critical and need to be included and which can be deferred until later. Predictive projects are less prone to scope creep while due to the nature of adaptive projects scope creep is easier to occur. Determining the Level of Automation Usually the level of automation can be defined in three categories… * low – system only provides simple record keepinga