5 ONTOLOGICAL INFLUENCE ON REQUIREMENT ENGINEERING The first step in requirement engineering

The reason that a SRS is needed should be rather obvious; if the requirements aren’t written down, how do the software engineers know what to program, and how does the client know what to expect? (Berezin) However, the SRS is often times skipped, or written at a very high level, lacking enough detail. Taking the user requirements and writing them into specifications is considered to be one of the most difficult steps in software development, and therefore engineers frequently attempt to bypass this step. It is also very time consuming – are the engineers wasting their time writing the SRS when they should be programming? In discussing this with Cheryl Lindauer, the Corporate Development Manager at Shoe Carnival, the answer is an outstanding NO! “The best investment any company can make is to write detailed SRS documents for every project, before beginning any coding. If we are in a time crunch and skip the SRS document,

Another way of successfully gathering information is by building a prototype or model of the system, so that users can test or get an idea of what the finished product will be like. With this they can determine issues, problems, or inconsistency with the system. Another important part of gathering information is organizing it so that it can be understood and put to proper use. I propose categorizing the requirements into functional requirements, operational requirements, technical requirements, and transitional requirements. The functional requirements define how the user thinks the system is functioning overall, the operational requirements define what background processes need to be executed in order for the system to work optimally over a period of time, the technical requirements define what technical issues that must be addressed in order to successfully implement the system, and the transitional requirements define the processes or steps needed to implement the system smoothly and successfully. ("Mind Tools", 2012).

Business requirements document (BRD) that provides additional details regarding the expectations (such as user, system, and functional) that must be met for achieving project goals

The purpose of this section is to identify the documentation that will be used for ensuring quality.

Functional requirements must address the quality characteristic of functionality while the other qualities of the characteristics should be concerned with other kinds of non-functional requirements. Applied Software Project Management states,

Many reasons exist for the extremely high failure rates of software projects but one major reason is poor communication between the end-user and the software developer which leads to a lack of definition or scope of work. One resolution to this problem is a well communicated document similar to a Software Requirements Specification (SRS). I used to belong to a discussion group that dealt with automation issues. The topic of software project failure and its causes was a constant topic of discussion. A common theme that was echoed by our members was that, most of the time projects fail due to unstable requirements that were not

Requirement Analysis: collect the business needs, document the requirements, and help team members to prepare Functional and enhancement Specification Document and Technical detail design document.

As noted by the National Research Foundation (1991), specifications describe software components, written by information security consultants to provide organizations precise, easy-to-read, module-level documentation of interfaces. Specifications facilitate system design, integration, and maintenance, and encourage reuse of modules. Further, as noted by Hackney (2011), specifications provide clarity and deeper understanding by encouraging prompt attention to inconsistencies, incompleteness, and ambiguities.

Specific goals of the process area are based around understanding the requirements, obtaining commitment to them, making changes to them as they evolve, keeping traceability to the products and making sure the plans and products are aligned to requirements. The organisation must understand what the requirements are in order to fulfil them, as any confusion or misplaced requirements can spell disaster later in the project. They must be aware of what they are setting out to complete. Requirements should be clearly stated and complete, while being possible for the organisation to carry out. After the requirements are understood, commitment needs to be made with whomever provided the requirements. Requirements can be changed as the project goes on, but wherever possible a firm commitment should be sought so that the organisation can have some more predictability on what they are setting out to do. If changes are necessary, either due to the needs of the customer or the restrictions of the process, the changes must be carefully documented and added to a change history. This is to ensure that the change is fully understood to both the organisation and the customer. If a change is to be made, it should be done correctly

The end result for not unclear requirements will result in frustration for both customers and developers. The customer’s frustration will be that the product will not support its essential task and the developer’s frustration will be to implement the customer’s essential requirements after the system has been implemented. Requirements’ gathering is very difficult because it necessitates the involvement of a number of stakeholders during the phase such as customers, users, requirement analyst, developers, testers, document writers, managers, legal staff, manufacturing staff and support staff. The main failures for requirements not

Software Requirement means a condition or capability that must be met or possess by a system to satisfy a contract, standard, specification or other formally imposed document. In this we come across with three types of requirements:

This chapter is the first of the two chapters that present empirical findings of the research. The aim of this chapter is to describe how requirement engineering is performed in the Saudi software firms. This section is divided into three sections. First, I report participant demographics following the thematic process used to identify the themes. Last, I report the RE process and technique presented in study participants answer.

According to IEEE (Institute of Electrical and Electronics Engineers), “Requirements traceability refers to the ability to define, capture and follow the traces left by requirements on other elements of the software development environment and the trace left by those elements on requirements.”

Detail in bullet points what is/are included within or excluded from the scope of this SRS (e.g. deliverables, product areas, etc).

The purpose of the software requirements specification is to produce the specification of the analysis task and also to establish the complete information about the requirements, behaviour and other constraints such as functional performance and so on.