System Development Techniques Individual Assignment

System Development Techniques

Diploma in Information Technology

Lesson 2

Learning outcomes After studying this chapter and the recommended reading, you should be able to:

• Discuss the systems requirements • Discuss the information-gathering techniques • Explain the documenting workflows with

activity diagrams

Systems Analysis Activities

• Third core process, – discover and understand the details. – aka systems analysis.

Systems Analysis Activities

• The activities are as follows: – Gather detailed information. – Define requirements. – Prioritize requirements. – Develop user-interface dialogs. – Evaluate requirements with users.

• By completing these activities, the analyst defines in great detail what the information system needs to accomplish to provide the organization with the desired benefits.

Gather Detailed Information

• Systems analysts (SA) obtain information from people by – interviewing or – watching them work.

• Obtain additional information by – reviewing planning documents and policy statements – study existing systems, including their documentation – looking at what other companies (particularly

vendors) have done when faced with a similar business need.

Gather Detailed Information

– try to understand an existing system by identifying and understanding activities of all the current and future users

• SA must become an expert in that business area. – For example, to implement a loan-processing system, the SA needs to

become an expert on the rules used for approving credit.

• The most successful SA become experts in their organization’s main business.

Define Requirements

• Uses gathered information to define requirements for the new system.

• System requirements include – functions the system must perform (functional

requirements) and such related issues – user-interface formats – requirements for reliability, performance, and

security (non functional requirements).

Define Requirements

• Creates models to record requirements. – Example of models: use case diagrams, activity

diagrams, and domain model class diagrams.

• Reviews the models with users • Refines and expands the models to reflect

new or updated information.

Prioritize Requirements

• Establish which requirements are most crucial for the system.

• Sometimes, users request additional system functions that are desirable but not essential.

• Need to ask which functions are truly important and which are fairly important but not absolutely required.

• Resources are always limited, it is important to know what is absolutely required.

Prioritize Requirements

• Scope Creep: System requirements tend to expand as users make more suggestions

• Requirements priorities help to determine the number, composition, and ordering of project iterations.

• High-priority requirements are often incorporated into early project iterations so analysts and users have ample opportunity to refine those parts of the system.

Develop User-Interface Dialogs

• User evaluating a user interface is an easy and simpler way to get feedback and gather information because the user can see and feel the system.

• To most users, the user interface is all that matters. • Developing user-interface dialogs (wireframe) is a

powerful method to document requirements.

Develop User-Interface Dialogs

• SA can – develop user interfaces via abstract models, such

as interaction diagrams and written dialogs, or – Develop storyboards or user-interface prototypes

on the actual input/output devices that users will use (e.g., a computer monitor, iPad, or smartphone).

Develop User-Interface Dialogs

• A prototype interface can serve as a requirement and a starting point for developing a portion of the system.

• A user-interface prototype developed in an early iteration can be expanded in later iterations to become a fully functioning part of the system.

Evaluate Requirements with Users

• SA usually use an iterative process to get user input to model requirements, return to the user for additional input or validation/feedback, and then incorporate the new inputs and refine the models.

• The processes of getting requirements, building models and prototypes, and evaluating them with users may repeat many times until requirements models and prototypes are complete and accurate.

System Requirements

• System requirements – all the activities the new system must perform or

support and the constraints that the new system must meet.

• Two categories: – functional and non-functional requirements.

Functional requirements

• Activities that the system must perform (i.e., the business uses to which the system will be applied).

• For example, a payroll system, the required business uses might include such functions as – “generate electronic fund transfers,” – “calculate commission amounts,” – “calculate payroll taxes,” – “maintain employee-dependent information,”,

Non-functional requirements

• Characteristics of the system other than those activities it must perform or support.

• FURPS – functional, usability, reliability, performance, and

security. • Functional: same as functional requirements defined

previously.

FURPS

• Usability requirements – operational characteristics related to users, such

as the user interface, related work procedures, online help, and documentation. • For example, the user interface for a smartphone app

should behave similarly to other apps when responding to such gestures as two-finger slides, pinching, and expanding. • Additional requirements might include menu format,

colour schemes, use of the organization’s logo, and multilanguage support.

FURPS

• Reliability requirements – how often a system exhibits such behaviours as

service outages and incorrect processing and how it detects and recovers from those problems.

FURPS

• Performance requirements – operational characteristics related to measures of

workload, such as throughput and response time. – For example, the client portion of a system might

be required to have a 0.5 second response time to all button presses, and the server might need to support

FURPS

• Security requirements – how access to the application will be controlled

and how data will be protected during storage and transmission.

– For example, the application might be password protected, encrypt locally stored data with 1024- bit keys, and use secure HTTP for communication among client and server nodes.

Stakeholders

• People who have an interest in the successful implementation of the system.

• For example, accounting system the stakeholders – bookkeepers, accountants, managers and

executives, customers, suppliers, auditors, investors.

Stakeholders

• Each stakeholder group interacts with the system in different ways,

• Each has a unique perspective on system requirements.

• Before gathering detailed information, the analyst identifies every type of stakeholder who has an interest in the new system and ensures that critical people from each stakeholder category are available to serve as the business experts.

Information-Gathering Techniques

• The following are common Information- Gathering Techniques • Interviewing users and other stakeholders • Distributing and collecting questionnaires • Reviewing inputs, outputs, and documentation • Observing and documenting business procedures • Researching vendor solutions • Collecting active user comments and suggestions

Interviewing users and other stakeholders

• Effective way to understand business functions and business rules.

• Most time- consuming and resource-expensive option. • SA does the following:

– Prepare detailed questions – Meet with individuals or groups of users – Obtain and discuss answers to the questions – Document the answers – Follow up as needed in future meetings or interviews

• Process may take some time, usually requires multiple sessions with each of the users or user groups.

Distributing and collecting questionnaires

• Enable SA to collect information from a large number of stakeholders.

• Even if the stakeholders are widely distributed geographically, they can still help define requirements through questionnaires.

• Used to obtain preliminary insight into stakeholder information needs, which helps to determine areas that need further research using other methods.

Reviewing inputs, outputs, and documentation

• Two sources of documentation. (External and Internal) – External to the organization • industry-wide professional organizations and other

companies. • may not be easy to obtain information from other

companies, • may be available in industry journals and magazines

report the findings of “best practices” studies.

Reviewing inputs, outputs, and documentation

- Internal to the organization • revieing internal documents and procedures. • good way to get a preliminary understanding of the

processes. • serve as visual aids for the interview and as the working

documents for discussion • helps identify business rules that may not come up in the

interviews. • helps reveal discrepancies and redundancies in the business

processes. • However, procedure documents frequently are not kept up

to date, and they commonly include errors. SA should review them with the users.

Observing and documenting business procedures

• observing business process in action helps to understand the current business functions and fundamental business needs,

• the processes could and often should change to be made more efficient.

• do not get locked into believing there is only one way of performing the process.

Researching vendor solutions

• Consulting firms often have experience with the same problems,

• Software firms may have packaged solutions for a particular business need.

• Taking advantage of existing knowledge or solutions can avoid costly mistakes and save time and money.

Collecting active user comments and suggestions

• Portions of the system are constructed and tested during each iteration.

• Users and other stakeholders perform the initial testing of system functions during the iteration in which those functions are implemented.

• They also test and use those same functions during later iterations.

• User feedback from initial and later testing is a valuable source of requirements information

Models

• A model is a representation or abstraction of some aspect of the system being built.

• There are dozens of different models that an analyst or designer might develop and use

Documenting Workflows with Activity Diagrams

• One effective way to capture workflow is with a UML activity diagram.

• An activity diagram describes the various user (or system) activities, the person or component that completes each activity, and the sequential flow of these activities.

Documenting Workflows with Activity Diagrams

• Activity diagram basic symbols

Documenting Workflows with Activity Diagrams

• The flattened ovals represent the individual activities in a workflow.

• The connecting arrows represent the sequence of the activities.

• The black circles denote the beginning and the ending of the workflow.

• The diamond is a decision point at which the flow of the process will either follow one path or another.

Documenting Workflows with Activity Diagrams

• The heavy solid line is a synchronization bar, which either splits the path into multiple concurrent paths or recombines concurrent paths.

• The swimlane represents an agent who performs the activities. – each agent follows a path parallel with other agents in the

workflow, as with swimmers in a swimming pool.

Documenting Workflows with Activity Diagrams

• Order fulfillment process

Documenting Workflows with Activity Diagrams

• Processing begins when the customer has completed the order checkout process and the warehouse begins order fulfillment.

• Omits many error-handling path- ways, including what happens if enough item stock is on hand to fulfill only part of an order.

Documenting Workflows with Activity Diagrams

• Ordering a product that has to be manufactured to match customer specifications.

Documenting Workflows with Activity Diagrams

• To show that the salesperson sends the order to Engineering, the diagram uses a new symbol to emphasize the transmission of the document between Sales and Engineering.

Documenting Workflows with Activity Diagrams

• After Engineering develops the specifications, two concurrent activities happen: Purchasing orders the materials, and Production writes the program for the automated milling machines.

Documenting Workflows with Activity Diagrams

• These two activities are completely independent and can occur at the same time.

• Notice that one synchronization bar splits the path into two concurrent paths and that another synchronization bar reconnects them.

Documenting Workflows with Activity Diagrams

• Finally, Scheduling puts the order on the Production schedule.

Summary

• System analysis activities are as follows: – Gather detailed information. – Define requirements. – Prioritize requirements. – Develop user-interface dialogs. – Evaluate requirements with users.

Summary

• The following are common Information- Gathering Techniques • Interviewing users and other stakeholders • Distributing and collecting questionnaires • Reviewing inputs, outputs, and documentation • Observing and documenting business procedures • Researching vendor solutions • Collecting active user comments and suggestions

Summary

• One effective way to capture workflow is with a UML activity diagram.

• An activity diagram describes the various user (or system) activities, the person or component that completes each activity, and the sequential flow of these activities.

Read

Textbook:

• Satzinger, Robert & Stephen Chapter 2