Question

3. Specify a technique that you think could be used to determine the validity and a technique that you think could be used to determine the completeness of gathered requirements for an automated in-store supermarket shopping system?

4. Describe what is meant by a domain requirement and explain why it could be challenging to recognize domain requirements by interviewing the stakeholders of an in-store supermarket shopping system?

Answer 1

While building a new software system based on the requirements provided by the customer, he may anticipate various functionalities and services that the software may offer. The requirements form the customers point of view may range from the core tasks the system expected to do and also even small details like the interface design, color scheme of the UI etc., Majority of the requirements specified by the customers includes implementation of tasks which were manually done that require automation either partially or completely. Sometimes we may also come across the situations where the customer anticipates the extension or redesigning of the existing automation or simply customizing the existing software components with the new requirements. Moreover, there will be requirements that need implementation which haven’t been done before .Whatever the situation is, the customers need the required functionality on the proposed system for a desired behavior.

In general terms, a requirement is an expression of a desired characteristic or the behavior. Requirements generally deal with the entities whose states, functions, properties which are anticipated within a system or software. For example the customer requires” authentication of the users through biometric devices to log in into the system “.This requirement statement will provide a general idea of the characteristics and functions of the system to some extent. It also provides what additional requisites that the system may need in order to implement this requirement. For our example we require a fingerprint or an iris sensor to read the biometrics from the users for authentication.

The following diagram shows the process of requirement gathering

The requirements specify various parameters and conceptual representation of the system form the end user’s side The above figure shows the approach for requirement gathering which is carried out in various stages and finally documented as a Software Requirements Specification(SRS) document which acts as a roadmap for the project during its lifecycle. The SRS document acts a formal artifact for designing the system model which specifies how the intended behavior of the system could be implemented .The requirements gathering is a process that involves various tasks namely Elicitation,Analysis,Specification and Validation usually done by requirements analyst or a system analyst

Requirement Elicitation:

This process involves collection of system requirements from the customers directly by asking questions or by examining the behavior of the existing systems or by demonstration of similar systems.

Requirement Analysis:

In this step the requirements are represented as prototypes in order to understand the desired behavior of the system. It also provides additional information related to the system which was not usually provided by the user like security, limitations of the system etc.,

Requirement Specification:

After a proper acceptance of the prototyped requirements, the system analysts decides to what extent requirements can be implemented and suggest any changes required for the prototype.

Requirement Validation:

In this step,the requirements implemented as a model is checked for a validity by testing whether the specification meets the requirements specified by the user to a satisfactory level

Techniques used for requirement gathering

Based on the system being implemented and its intended usage environment, there are different approaches for collecting requirements from the users.The following are the common approaches used for requirements gathering:

• Interviews
• Questionnaires/Surveys
• Analyzing Existing Systems
• User Observation
• Prototyping etc.,

Need for validation

Requirements involve checking of the requirements defined that the customer really needs. In order to verify the validity of requirements and their acceptability of implementation, we perform requirements validation.This process checks errors at the initial phase of development as the errors may cause excessive rework if they were detected later in its life-cycle.

The requirements validation process includes:

• Completeness checks
• Consistency checks
• Validity and verifiability checks
• Realism checks
• Ambiguity checks

There are various techniques followed to preform above specified validity checks like:

Test case generation:
This verifies whether a requirement specified in the SRS document is a valid one or not by generating a test case.If the test case is impossible to generate foe a particular requirement,it should be difficult to implement so that the requirement will be reconsidered

Prototyping:
In this validation, an experimental version or a model of the proposed system is built for checking the validity of the requirements by collecting the feedback of its functionality.

Requirements Reviews:
In this approach, the requirements presented in SRS are carefully reviewed by stakeholders including the end users to check for ambiguity or errors in the requirements specified

Automated Consistency Analysis:
This approach is implemented by using CASE tools to test consistency of the system to generate a report of all the inconsistencies found in the system implementation

Walk-through:
A walkthrough is a non formal validation technique that involves usability tests conducted on a group of users to collect the feedback of the system usability requirements and review the system

For our project, test case generation and Requirement review is a best approach to determine the completeness of gathered requirements for an automated in-store supermarket shopping system

Domain requirements

During the requirement gathering process, the requirement analysts require to communicate with the customer to collect the information of what services the system is expected to provide and also various parameters of the system specified by the customer. The domain requirements are the environment specific requirements which decide the behavior of the system which it is needed to operate within. For example domain requirements of medical record information system is different from an airline reservation system. The former one deals with the data relevant to patient records, diagnostic reports etc., whereas the latter one deals with data relevant to passenger boarding , ticketing, flight information etc.,

Based on the end user’s business domain , the domain requirements can be framed.

Sometimes the domain requirements may make use of specialized terminologies and representations which may be needed to consider with due care as the software engineers may get confused while impelementation

The domain requirements are mostly non-functional but they need careful handling as any deviations in the implementation of domain specific requirements may lead to rework

Since the requirements are collected in various methods like interviews, questionnaire etc., we may require prioritization of the requirements gathered so far as different users have different preferences and they should be clearly documented and categorized .Also , the preparation of questionnaire affects the coverage of various requirements of the proposed system. Sometimes , involving techniques that includes domain experts like focus groups or brainstorming, it will yield most positive and favorable feedback from the stake holders .

The following are the possible challenges faced while collecting domain requirements by interviewing the stakeholders of an in-store supermarket shopping system:

• Changing requirements of the stakeholders
• Specifying non-definite or ambiguous requirements
• stakeholders having limited knowledge in certain technical areas
• Stakeholders having Conflicting priorities
• Lack of active communication from the stake holders
• Limited access to the information of different departments of supermarket for the stakeholders
• Lack of co-operation and communcation between different departments
• Customer not willing to extend the IT equipment or additional expenses towards hardware equipment.