Karolina Muszyńska Based on http://www.csun.edu/~dn58412/IS431/IS431_SP13.html

2

     • Scope Definition Phase – WHAT PROBLEM Is the project worth looking at to solve problem?

• Problem Analysis Phase – WHAT ISSUES Is a new system worth building?

• Requirements Analysis Phase – WHAT REQUIREMENTS WHAT do the users need and want from the new system?

• Logical Design Phase – WHAT TO DO WHAT must the new system do to satisfy users’ needs?

• Decision Analysis Phase – WHAT SOLUTION WHAT is the best solution among others?

3

4

Requirements Analysis Tasks

5

3. Requirements Analysis Tasks

 Task 3.1: Identify System Requirements ◦ Functional requirements outputs, stored data.

: activities and services provided by a system: business functions, inputs, ◦ Nonfunctional requirements : features, characteristics defining a satisfactory system: performance, documentation, budget, ease of use and learn, cost saving, time saving, security ◦ Deliverable: draft functional and nonfunctional requirements: improvement objectives and related input, output, processes, stored data to fulfill the objectives 6

3. Requirements Analysis Tasks

 Task 3.2: Prioritize Requirements ◦ Mandatory vs. desirable requirements ◦ Time boxing : deliver the system in a set of subsequent versions in a time frame. The first version satisfies essential and highest prioritized requirements.

 Task 3.3: Update the Project Plan ◦ If requirements exceed original vision: reduce the scope or increase the budget ◦ Deliverable: consolidated system requirements (completed requirements and priorities) 7

      The system may cost more than projected.

The system may be delivered later than promised.

The system may not meet the users’ expectations and that dissatisfaction may cause them not to use it.

Once in operation, the costs of maintaining and enhancing the system may be excessively high.

The system may be unreliable and prone to errors and downtime.

The reputation of the IT staff of the team is tarnished because any failure, regardless of who is at fault, will be perceived as a mistake by the team.

8

       Consistent – requirements are not conflicting or ambiguous.

Complete – requirements describe all possible system inputs and responses.

Feasible – requirements can be satisfied based on the available resources and constraints.

Required – requirements are truly needed and fulfill the purpose of the system.

Accurate – requirements are stated correctly.

Traceable – requirements directly map to the functions and features of the system.

Verifiable – requirements are defined so they can be demonstrated during testing.

9

    Problem discovery and analysis Requirements discovery Documenting and analyzing requirements Requirements management to handle changes 10

  ◦ ◦ Analyzing requirements to resolve problems of: ◦ Missing requirements ◦ Conflicting requirements ◦ Infeasible requirements ◦ Overlapping requirements ◦ Ambiguous requirements Formalizing requirements Requirements definition document Communicated to stakeholders or steering body 11

A requirements definition document should consist of the following: ◦ ◦ ◦ ◦ The functions and services that the system should provide.

Nonfunctional requirements including the system’s features, characteristics, and attributes.

The constraints that restrict the development of the system or under which the system must operate.

Information about other systems that the system must interface with.

12

       Sampling of existing documentation, forms, and databases. Research and site visits. Observation of the work environment. Questionnaires. Interviews. Discovery Prototyping. Joint requirements planning (JRP) / Joint application development (JAD) 13

Joint requirements planning (JRP) – a process whereby

highly structured group meetings

(having defined agenda, key representatives) are conducted for the purpose of analyzing problems and defining requirements. (JRP is a subset of a more comprehensive joint application development or JAD technique that encompasses the entire systems development process).

14

  • • Model-driven Analysis • Structured analysis • Information engineering • Object-oriented analysis Accelerated Systems Analysis Discovery prototyping Rapid Architected Analysis 15

Model-driven Analysis emphasizes the drawing of graphical system models to document and validate both existing and/or proposed systems. Ultimately, the system model becomes the blueprint for designing and constructing an improved system.

16

   Structured Analysis: a PROCESS-centered technique to analyze an existing system and define business requirements for a new system. The models illustrate the system’s components: (functions, tasks) and their associated inputs processes , outputs , and files Information Engineering (IE): a DATA-centered, but process-sensitive technique to plan, analyze, and design information systems. IE illustrate and synchronize the system’s data and processes .

Object-oriented Analysis (OOA): a technique that integrates data and process concerns into constructs called OBJECTS. OOA illustrate the system’s objects from various perspectives such as structure and behavior .

17

 Accelerated Systems Analysis approaches emphasize the construction of prototypes to more rapidly identify business and user requirements for a new system • • Discovery Prototyping Rapid Architected Analysis 18

Discovery Prototyping

   Discovery Prototyping – a technique used to identify the users’ business requirements by building a small scale, representative or working model of the users’ requirements in order to discover or verify them.

Advantages • Prototypes cater to the “I’ll know what I want when I see it” way of thinking that is characteristic of many users and managers Disadvantages • • • Can become preoccupied with final “look and feel” prematurely Can encourage a premature focus on, and commitment to, design Users can be misled to believe that the completed system can be built rapidly using prototyping tools 19

Rapid Architected Analysis

 Rapid Architected Analysis – derive system models from existing systems or discovery prototypes.

 Reverse Engineering – the use of technology that reads the program code for an existing database, application program, and/or user interface and automatically generates the equivalent system model.

20