Safety Management
Risk Management
Railway RAMS
Combat Management System
Airport Management System
Energy Management System
Software Requirement Management
The hardest part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all of the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later (Brooks 1995). Eliciting, analyzing, and writing good requirements are the most difficult parts of software engineering. If you don't get the requirements right, it doesn't matter how well you do anything else. One can end up doing a perfect job of building the wrong product.
If software requirements are not right, companies will not end up with the software they need. Requirements must be determined and agreed to by the customers, users, and suppliers of a software product before the software can be built. The requirements define the what of a software product.
Most software practitioners just talk about the requirements. However, by recognizing that there are different levels and types of requirements, as illustrated in Figure, practitioners gain a better understanding of what information they need to elicit, analyze, specify, and validate when they define their software requirements.
Figure: Software Requirements[Karl Wiegers (2004)]
Business requirements define the business problems to be solved or the business opportunities to be addressed by the software product. In general, the business requirements define why the software product is being developed. Business requirements are typically stated in terms of the objectives of the customer or organization requesting the development of the software.
User requirements look at the functionality of the software product from the users perspective. They define what the software has to do in order for the users to accomplish their objectives. Multiple user level requirements may be needed in order to fulfill a single business requirement.
The products functional requirements that define the software functionality must be built into the product to enable users to accomplish their tasks, thereby satisfying the business requirements. Multiple functional level requirements may be needed to fulfill a user requirement.
As opposed to the business requirements, business rules are the specific policies, standards, practices, regulations, and guidelines that define how the users do business (and are therefore considered user-level requirements). The software product must adhere to these rules in order to function appropriately within the users domain.
User-level quality attributes are nonfunctional characteristics that define the software products quality. Sometimes called the ilities, quality attributes include reliability, availability, security, safety, maintainability, portability, usability, and other properties.
A quality attribute may also translate into product-level nonfunctional requirements that specify the characteristics the software must possess in order to meet that attribute. For example, an ease-of-use requirement might translate into nonfunctional requirements for response time to user commands or report requests.
The external interface requirements define the requirements for the information flow across shared interfaces to hardware, users, and other software applications outside the boundaries of the software product being developed.
The constraints define any restrictions imposed on the choices that the supplier can make when designing and developing the software. For example, there may be a requirement that the completed software use no more than 50 percent of available system memory or disk space in order to ensure the ability for future enhancement.
The data requirements define the specific data items or data structures that must be included as part of the software product. For example, a payroll system would have requirements for current and year-to-date payroll data.
Reliability Centre India has wide experience in developing software based Information Systems in different domains. We will engineer the complete system from the concept stage to requirements, design, testing, operation and maintenance phase in the system lifecycle.
Project in Zambia
We managed US $2.3 million project of laying Optical Fibre cable and setting up antennas on Mobile Telephone towers in Malawi and Zambia.

Projects with Siemens
We undertook RAMS analysis of BHS system designed by Siemens for their projects in India and Thailand.

Software Audit
We have conducted manual testing and auditing of the software. Common problems and software failures encountered in e-governance projects.