Outsource Technical Analysis Process at O2I

Many a software project has failed due to an incomplete or inaccurate analysis process, especially technical analysis. Technical Analysis is a key step while developing a software application. It can be useful to-

• Confirm with the customer that we have gathered all business requirements accurately, and begin with designing and building the application after approval from the customer.
• It can be used by the Designers and Developers as a reference when building the application.
• It can be used by the client to verify that the final application actually matches what was initially agreed upon.

Components of Technical Analysis

There are two parts to Technical Analysis – drafting an Application Specification Document and generating Use Cases.

An Application Specification Document is usually derived from the Requirements Documentation from a Business Analyst. This document briefly specifies various features of the application, details parameters of how the application will be built, etc.

A sample structure of an Application Specification Document for a typical Web Development project would be as follows:

1. Introduction
   • Background
   • Purpose
   • Scope
   • Definitions, Acronyms and Abbreviations
   • References
   • Overview
2. Overall Description
   • Use-Case Model Survey
   • Assumptions and Dependencies
3. Specific Requirements
4. Non-functional Requirements
   • Browser Compatibility
   • Layout
   • Graphics and Web Design
   • Resolution
   • Log History Analysis
   • Cookies
   • SMTP Server
   • Secure Sockets Layer
   • Accessibility
   • Performance
5. Payment Schedule

Depending on the project, you may need to elaborate or discard a few of these points but generally, this is how a Software Requirements Specification is laid out. It shows the intended behavior of the project and behavior can be expressed in the form of tasks, functions or services.

Use Cases

Use Cases are documents that help capture and detail requirements of the project. They are usually written in casual English for easy comprehension but when required, Flow Charts, Pseudo-Code, etc may be used to explain features in the Use Case. Use Cases are now a widespread practice that originally came from the Object-Oriented Programming Community.

Use Cases define goal-based relationships between actors and various functions in the application. An actor is a term that comes from UML. They are the external entities who use the application – visitors, administrators, staff, an external interacting application, etc. There are usually two types of actors – a Primary actor and a Secondary actor. A Primary Actor is one who requires assistance of the system for their goal to be satisfied. A Secondary Actor is one who the system needs assistance from in order to help Primary Actors achieve their goal.

Every Use Case needs to describe in detail the necessary interaction required between various actors and the application in order to deliver a service that satisfies an actor's goal. A Use Case also needs to detail any possible alternate flows that could help an actor satisfy his goal. Alternate flows also need to describe methods that could lead to a failure of the application due to errors, etc.

System Internals are not part of a Use Case. A Use Case merely describes the actor, an actor's possible interaction with the application, optionally the goal that the actor may have set out to achieve and various ways of achieving it.

There are many formats for Use Cases. A sample Use Case for a login feature would be as follows:

Terminology

The Use Case ID is a unique ID given to each Use Case for future reference.

The Actors Involved section points to the various actors that can access the Use Case.

The Basic Flow of the Use Case details the interaction that needs to happen between the Primary Actor and the Application.

The Alternative Flow details possible failures of the Basic Flow, and how they should be handled.

Special Requirements specify if there are any requirements that the functionality needs – for example, “Needs to be SSL secured”, etc.

Pre-Conditions define conditions that must be true before the Use Case can be accessed. For example, “User must visit the Member Login Page”, “User must have logged into the system to access this panel”, etc.

Post-Conditions define what happens when everything goes right.

Extension Points define other Use Cases that this Use Case touches on. For example, if the Username/Password is validated and the Use Case is successful, they are redirected to the Member Panel. The “Member Panel” is a separate Use Case and hence defined here as an Extension Point. These are typically underlined links that take the reader directly to the Extension Point.

Technical Analysis is a key step in ensuring the success of your software project, and is essential in understanding the technical requirements of your proposed software project.

Dedicated business analysts at O2I possess comprehensive expertise in all domains - technology, process and business strategy.

Our Related Services

Outsource your Software Consulting to India

Do you require high value software consulting services? Why not consider outsourcing to India? Indian software consultants offer carefully analyzed, dynamic software solutions that will bridge the gap between your business vision and organizational processes.

Read more about O2I's Requirements Analysis Process and Project Quality Process.

Inquire Here with your requirements and our Client Engagement Team will contact you in 24 hours.