Domain Analysis before software development

Every software falls into some kind of domain category. Experienced people in this field can be of great help in analyzing general and specific requirements.

brain attack

Informal debates are held between various stakeholders and all their contributions are recorded for further requirements analysis.

prototyping

Prototyping is the creation of a user interface without adding detailed functionality to allow the user to interpret the functionality of the intended software product. This helps to better understand the requirements. If the developer’s reference software is not installed on the client side, and the client is unaware of their own requirements, the developer creates a prototype based on the requirements originally mentioned. The prototype is shown to the client and feedback noted. Customer feedback serves as an input to collect requirements.

observation

A team of experts visits the client’s organization or workplace. They oversee the actual operation of existing installed systems. They oversee the client-side workflow and how execution issues are resolved. The team itself draws some conclusions that help shape the requirements expected of the software.

Software requirements Specifications

Gathering software requirements is the backbone of an entire software development project. Therefore, they must be clear, correct and well-defined.

Complete software requirements specifications should be:

Clear

Right

consistent

Consistent

understandable

modifiable

verifiable

priority

unambiguous

traceable

Reliable source

Software Requirements

We must try to understand what requirements might arise during the requirements discovery phase and what requirements are expected from the software system.

In general, software requirements should be divided into two categories:

Functional requirements

Requirements relating to the functional aspect of the software fall into this category.

They define functions and functionality in and out of the software system.

Examples –

The search option is provided to the user to search from various accounts.

The user should be able to send any report to management.

Users can be divided into groups, and groups can be given separate rights.

Must comply with business rules and administrative functions.

The software is designed with downward compatibility

Non-functional requirements

Requirements that do not relate to the functional aspect of the software fall into this category. They are implicit or expected features of the software that users assume.

Non-functional requirements include −

Safety

logging

Storage

configuration

Performance

Price

Interoperability

flexibility

Disaster recovery

availability

Requirements are classified logically as

Must be: The software cannot run without them.

Must have: Enhancement of software functionality.

May Have: The software may still function properly with these requirements.

Wish List: These requirements do not meet any of the goals of the software.

When developing software, it is necessary to implement “Must have”, “Must have” subject to stakeholder debate and deniability, while “may have” and “wish list” can be retained for software updates.

User interface requirements

The user interface is an important part of any software or hardware or hybrid system. Software is widely distributed if it –

easy to operate

quick response

handle errors efficiently

providing a simple but consistent user interface

User acceptance mainly depends on how the user can use the software. The user interface is the only way users experience the system. A well-functioning software system should also be equipped with an attractive, clear, consistent, and responsive user interface. Otherwise, the functionality of the software package cannot be used in a convenient way. A system is said to be good if it provides the means to use it effectively.

The UI requirements are briefly mentioned below −

The content of the presentation

Easy navigation

Simple interface

responsive

Consistent UI elements

Feedback mechanism

Default settings

Purposeful Layout

Strategic use of color and texture.

Provide background information

User-centric approach

Group view settings.

Software systems analyst

A systems analyst in an IT organization is a person who analyzes the requirements for a proposed system and ensures that the requirements are properly and correctly framed and documented. The role of an analyst begins in the analysis phase of the SDLC software. The analyst is obliged to make sure that the developed software meets the requirements of the client.

Systems analysts have the following responsibilities:

Analysis and understanding of the requirements of the intended software

Understanding how the project will contribute to the organization’s goals

Identify sources of requirements

Requirements check

Develop and implement a requirements management plan

Documentation of business, technical, process and technology requirements

Coordination with clients to prioritize requirements and resolve and ambiguity

Finalize the acceptance criteria with the client and other interested parties

Software metrics and metrics

Software measures can be understood as the process of quantifying and symbolizing various attributes and aspects of software.

Software metrics provide measurements for various aspects of the software process and software product.

Software measures are a fundamental requirement of software development. Not only do they help control the software development process, but they also help maintain the superior quality of the final product.

In the words of Tom DeMarco (a) (Software Engineer): “You can’t control what you can’t measure.” According to him, it is very clear how important software measures are.

Let’s see some software metrics:

The size of the metric – LOC (Lines of Code), is mainly calculated in thousands of delivered lines of source code and is denoted as KLOC.

The Point Count function is a measure of the functionality provided by the software. The Point count function determines the size of the functional aspect of the software.

Complexity Metrics – McCabe’s cyclomatic complexity quantifies an upper bound on the number of independent paths in a program, which is perceived as the complexity of the program or its modules. It is presented in terms of graph theory concepts using a control flow graph.

Quality Metrics – Defects, their types and causes, consequences, intensity and their significance determine the quality of the product.

The number of defects found during the development process and the number of defects reported by the customer after the product is installed or delivered to the customer side determine the quality of the product.

process metrics. At various stages of the SDLC, the methods and tools used, company standards, and development efficiency are metrics for the software process.

Resource Metrics – Effort, time, and various resources used provide metrics for measuring resource.

The size of the metric – LOC (Lines of Code), is mainly calculated in thousands of delivered lines of source code and is denoted as KLOC.

The Point Count function is a measure of the functionality provided by the software. The Point count function determines the size of the functional aspect of the software.

Quality Metrics – Defects, their types and causes, consequences, intensity and their significance determine the quality of the product.

The number of defects found during the development process and the number of defects reported by the customer after the product is installed or delivered to the customer side determine the quality of the product.

Previous PostNextNext Post