In: Computer Science
The process to gather the software requirements from client, analyze and document them is known as requirement engineering. It is an important phase in the Software Development Lifecycle (SLDC) process. It is enormously helpful in developing effective softwares and reducing software errors at the early stage of the software development.
The top 5 requirement elicitation methods or activities are:
1. Interviews
2. Brainstorming sessions
3. Facilitated Application Specification Technique (FAST)
4. Quality Function Deployment (QFD)
5. Use Case Approach
As for class project Brainstorming sessions would be the most perfect because:
1. It is a group technique where every idea is documented so that everybody can see it.
2. It is intended to generate lot of new ideas , hence providing a platform to share views.
3. A highly trained facilitator is present to handle group problems and group conflicts.
4. Finally a document is prepared which consists of the list of requirements and their priorities, if possible.
User requirements must be understandable to all the users and stakeholders. User requirements need to be discussed in the business domain in any way which is clearly understandable to the client(s). The most important is that user requirements should contain technical terms as less as possible, for people tend to avoid things they don't understand. So there User Requirements come to play, to make keep them intellectually involved. From a developer's perspective, this is very helpful to confirm with the client before spending thousands of hours on building some code and later turning out to be useless to the client(s).
System requirements are meant for the development team to see how efficiently can things be developed using available technologies while staying on client's terms. System Requirements also come handy in a team where there are some arrogant developers. There might be some who think themselves to be the boss and act naive which puts the deal in an unagreeable situation. So these requirements are veey useful to keep the whole team working on same terms.
As a note, sometimes non-technical uses and clients or stakeholders fail to understand the System Requirements and keep on demanding adamantly which creates chaos. So clients and development team must be come to a point of negotiation so expect a better output. Thus we need effective communication and mutual understanding. So we need both, User Requirements and System Requirements.
A Functional Requirement describes what a system or software should do whereas a Non-functional Requirement describes how should it do. For example, a system should be developed to send necessary notifications on performing some particular tasks, that's a Functional Requirement. And the delay it should make, or whether it should pop-up or put a silent notification, that comes under Non-functional Requirements. A Functional Requirement describes the behaviour of a system whereas a Non-functional Requirement describes the characteristics of the behaviour of that system.
For the success of a software project, all of the above requirements are necessary, more or less. Because without one or the other, a development would never be purely satisfactory. Yet, User Requirements should be given a priority as much as possible because all matters is the user satisfaction after all.
Brainstorming is of course a very important method for gathering user requirements. People all together point out several minor possibilities and necessities a client maybe happy with which would be missed out otherwise. In a team development project, brainstorming really helps in locating a needle in a haystack.
The other important requirement gathering technique would be Document Analysis. Evaluating the documentation of a present system can assist when making AS-IS process documents and also when driving the gap analysis for scoping of the migration projects. In today’s world, you will also be determining the requirements that drove making of an existing system- a beginning point for documenting all current requirements. Chunks of information are mostly buried in present documents that assist you in putting questions as a part of validating the requirement completeness.