SOFTWARE REQUIREMENT ANALYSIS


A SURVEY BY THE CIO MAGZINE STATES THAT 71% OF THE FAILED SOFTWARE PROJECTS ARE TRACED TO POOR REQUIREMENT ANALYSIS

Software Requirement Analysis Approach

The overall approach to requirements capture is grounded in accepted international standards, in particular: ISO/IEC/IEEE 12207:2017, ISO 9241-210:2010 ISO/IEC/IEEE 12207:2017 provides a standard for describing the processes involved in developing and maintaining software, throughout the software lifecycle. Because of the generality of the situations it aims to cover, it was developed to be modular and flexible so that it can be adapted to the needs of projects that adopt it. Note that, while Si3 Digital is not developing a system per se, these principles still hold, although we replace user by the more generic term stakeholder. The motivation for introducing this additional standard is to emphasize Si3 Digital’ focus on iterative development and stakeholder-centricity.

Rapid Case Study

The Rapid Case Studies are broad descriptions, carried out at the start of the requirements gathering process. The aim of this deliverable is to overcome the “chicken and egg” situation described in scope and thus to “bootstrap” requirements gathering and the project as a whole, by providing a starting point for iterative engagement between client and Si3 Digital. To allow the technology partners to develop some understanding of the application domains and the needs of the stakeholders, and to start thinking about how their business ideas can support these needs through concrete outputs.

 

Lets identify the detail behind business challenges and finding solutions

GET IN TOUCH

Stakeholder Analysis

Broadly considered, a stakeholder is any person (or group of people) who may either have impact upon a project or be impacted by it. For the purposes of software requirements analysis, a stakeholder is considered to be anyone with an interest (actual or potential) in the data or metadata involved in the application domains addressed, an interest that may be direct (e.g. people that produce or use the data) or indirect (e.g. staff responsible for data management infrastructure).

Scenario Development

A scenario is a free-text narrative of a sequence of events involving one or more actors or personas (i.e. stakeholders acting as representatives of particular roles), especially one that describes interactions between personas and an actual or proposed computer-based system. Scenarios can be described at varying levels of detail, ranging from a short summary paragraph to a detailed description, and can cover quite different timeframes, from a single user interaction with a system to a long-term preservation scenario. The interactions described in a scenario generally have a functional goal, and rather than attempting to capture a large class of interactions in abstract form (as in e.g. UML-based use cases) they provide concrete stories that serve as exemplars of a larger class of interactions.

You can stay rest assured that we will only analyze what your business needs

Identification & Management of Requirements

The core part of the requirements gathering process will naturally be the identification of individual requirements. Many requirements will be identified during the process of compiling the deliverables from the methods described above, especially scenario development. The scenarios in particular will form a basis that enables us to scope the areas in which additional information needs to be collected, and to categorize the requirements that are identified.

Prioritization of Requirements

Each requirement should be prioritized into High, Medium or Low, where Low still indicates a requirement that is of some importance – requirements that are of no importance will be omitted.

Mock-up Development

Each requirement should be prioritized into High, Medium or Low, where Low still indicates a requirement that is of some importance – requirements that are of no importance will be omitted.

Identifying the data

This initial stage will identify, classify describe and locate the relevant data and existing metadata, as well any identifiable contextual information that can help in understanding the data. Contextual information includes such material as documentation, workflows, policies, and so forth. Initially, this will be a broad-brush activity, to map out the landscape; subsequent iterations will describe selected data objects or groups of data objects in more detail.

Organizing the data

Once key data objects or categories of data object have been identified, we will describe their lifecycles. The data lifecycle represents the different phases of activity that impact upon the data; understanding these lifecycles is important if stakeholders are to manage, understand and reuse the data effectively.

Data Lifecycles

The previous stage identifies and describes the various data objects – however, these objects do not exist in isolation, and a key part of the data inventory will be to organize the objects in a way that reflects not only the classification of the data (what sort of thing it is) but also the relationships and dependencies between them, whether explicit or implicit.

Scoping Evaluation

As part of evaluation, project outputs will be investigated and evaluated in relation to concrete examples of scenarios and requirements, which are likely to form only a subset of those identified and described. These examples should be relevant to the needs of the stakeholders, but – as this is a research project – at the same time they need to be challenging enough to contribute to the research goals of the project. In particular, the data used should be representative of the complexity of the data and metadata available, and should involve the typical data lifecycles and policies operative in the application domains.

Workshops

Workshops with the stakeholders will be organized. The format will vary depending on the specific purpose of the workshop, and the stage of the project; however, they will include activities.