Unit -2 : Requirment Analysis

Statement of system scope

When it comes to project planning, defining the project scope is the most critical step. In case if you start the project without knowing what you are supposed to be delivering at the end to the client and what the boundaries of the project are, there is a little chance for you to success. In most of the instances, you actually do not have any chance to success with this unorganized approach.

If you do not do a good job in project scope definition, project scope management during the project execution is almost impossible.

The main purpose of the scope definition is to clearly describe the boundaries of your project. Clearly describing the boundaries is not enough when it comes to project. You need to get the client’s agreement as well.

Therefore, the defined scope of the project usually included into the contractual agreements between the client and the service provider. SOW, or in other words, Statement of Work, is one such document.

In the project scope definition, the elements within the scope and out of the scope are well defined in order to clearly understand what will be the area under the project control. Therefore, you should identify more elements in detailed manner and divide them among the scope and out of scope.

How to Define the Project Scope or system scope

When the project is about to be funded, there should be a set of defined deliveries and objectives for the project. There can be a high level-scope statement prepared at this level.

This high-level scope statement can be taken from the initial documents such as SOW. In addition to the SOW, you need to use any other document or information in order to further define the project scope at this level.

In case, if you feel that you do not have enough information to come up with a high-level scope statement, you should then work closely with the client in order gather necessary information.

Project objectives can be used for defining the project scope. As a matter of fact, there should be one or more deliveries addressing each project objective in the project. By looking at the deliverables, you can actually gauge the project scope.

Once you get to know the main deliverables of the project, start asking questions about the other processes and different aspects of the project.

First identifying and clearly defining the out of scope also helps you to understand the scope of a project. When you go on defining the out of scope, you will automatically get an idea of the real project scope. In order to follow this method, you need to have a defined scope up to a certain level.

Whenever you identify an item for the scope or out-of-scope, make sure you document it then and there. Later, you can revisit these items and elaborate more on those.

Once you have successfully defined the scope of the project, you need to get the sign-off from the related and applicable parties. Without proper sign-off for the scope, the next phases of the project, i.e., requirements gathering, might have issues in executing.

Scope Creep

Scope creep is something common with every project. This refers to the incremental expansion of the project scope. Most of the time, the client may come back to the service provider during the project execution and add more requirements.

Most of such requirements haven’t been in the initial requirements. As a result, change requests need to be raised in order to cover the increasing costs of the service provider.

Due to business cope creep, there can be technological scope creep as well. The project team may require new technologies in order to address some of the new requirements in the scope.

In such instances, the service provider may want to work with the client closely and make necessary logistic and financial arrangements.

isolation of top level processes and entities and their allocation to physical elements

In software engineering, isolation of top level processes and entities refers to the separation and abstraction of high-level software components from lower-level hardware and systems. This means that software components are designed and developed in a way that they do not depend on or interact with specific hardware or software elements.

Allocation of these top level processes and entities to physical elements is the process of assigning or mapping the abstract software components to concrete hardware components such as CPU, memory, or storage devices. This mapping is done to ensure that the software components can be executed on a specific hardware platform.

The purpose of isolating top level processes and entities and allocating them to physical elements is to increase the modularity, scalability, and reliability of software systems. It allows software engineers to focus on the development of the high-level software components without worrying about the underlying hardware details. This leads to a better software design, which is easier to maintain and modify over time.

In summary, isolation of top level processes and entities and their allocation to physical elements is a key aspect of software engineering that ensures the design, development, and deployment of software systems that are scalable, reliable, and modular

refinement and review

Refinement and review are two important stages in requirement analysis, which is the first step in the software development process.

Refinement is the process of breaking down the high-level requirements into more detailed and specific requirements. This stage is important because it ensures that all the stakeholders agree on the same understanding of what the software needs to do. The refinement process usually involves detailed discussions between the stakeholders and the software development team to determine the functionality, performance, and quality requirements of the software.

Review is the process of evaluating and verifying the refined requirements to ensure they are complete, correct, and feasible. This stage is critical to ensure that the requirements accurately reflect the stakeholders’ needs and that the software development team has a clear understanding of what needs to be built. The review process involves a thorough review of the requirements by stakeholders, end-users, and experts to identify any gaps or ambiguities in the requirements.

Both refinement and review are important for ensuring that the requirements are well-defined and that the software development process can proceed smoothly. They help to minimize the risk of misunderstandings, miscommunications, and rework during the development phase, which can save time and resources in the long run.

In conclusion, refinement and review are key components of the requirement analysis process that help to ensure the requirements are well-defined and that the software development process proceeds smoothly. They help to minimize the risk of misunderstandings and rework, leading to more efficient and effective software development.

Analyzing a Problem: The first step in developing software is to identify and analyze the problem that the software is intended to solve. This involves gathering requirements, understanding user needs, and defining the scope of the software.

Creating a Software Specification Document: Once the problem is understood, the next step is to create a software specification document, which outlines the detailed requirements, functionalities, and design of the software. This document serves as a blueprint for the development of the software and should be reviewed for correctness, consistency, and completeness.

Review for Correctness, Consistency, and Completeness: Before the software development process begins, the software specification document should be reviewed for correctness, consistency, and completeness. This review process ensures that all requirements are clearly defined, all functionality is properly specified, and the design is feasible. A review by multiple people can help identify any gaps or inconsistencies in the specification document and ensure that it meets the needs of the user.

In summary, analyzing a problem, creating a software specification document, and reviewing it for correctness, consistency, and completeness are critical steps in the software development process and help to ensure that the end product meets the needs of the user and is developed in a structured and efficient manner.