Lesson 2

Systems Analysis Activities

1. Gather detailed information.
2. Define requirements.
3. Prioritize requirements.
4. Develop user-interface dialogs.
5. Evaluate requirements with users

Gather Detailed Information

• Systems analysts (SA) obtain information from people by interviewing / observing.

Define requirements

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

System requirements include

1. functions the system must perform (functional requirements) and such related issues
2. user-interface formats
3. requirements for reliability, performance, and security (non functional 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,usersrequestadditionalsystem 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
• 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) isa powerful method to document requirements.

• SA can

  • develop user interfaces via abstract models, such as interaction diagrams and written dialogs
  • Develop storyboards or user-interface prototypes on the actual input/ouput devices that users will use

• 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 a early iteration can be expanded in later iterations to become a fully functioning part of the system

Evaluate Requirements with users

System Requirements

Functional requirements

Non-functional requirements

FURPS

Stateholders

Interviewing users and other stakeholders

Distributing and collecting questionaires

Reviewing inputs, outputs and documentation

Observing and documenting business procedures

Researching vendor solutions

Collecting active user comments and suggestions

Models

Documenting Workflows with Activity Diagrams