Category Retirement Election in Depth

Software Requirement and Their Types

Software Requirement and Their Types

A system or software requirement in simple terms is a condition or capability that somebody i.e a business / client needs or wants. It may be a distinctly new application or an enhancement feature of an existing application or the need of rectification of an existing error or limitation.

  • Conscious Requirement or Known Spoken –
    • Those, which the stakeholders of the proposed system believe to be necessary or essential.
  • Unconscious Requirement i.e forgotten or unspoken –
    • Those, which have not been mentioned by the stakeholders of the proposed system because they may not be required right at the present moment.
    • Those, which are unknown to some stakeholders and not spells out but needed by some other stakeholders who have not yet been consulted.
    • Those, which have already been satisfied by some of the existing processes manual or automated.
  • Functional Requirement –
    • Those, which specify what the proposed system has to do and traceable to specific source.
  • Non-functional Requirement –
    • Those, which are quality requirements, which specify how well the proposed system should do and what it is supposed to do such as
      • System performance
      • Availability
      • Reliability
      • Usability
      • Flexibility
      • Maintainability
      • Legal Issue related requirement

Process Steps Involved in Elicitation of Requirement

Process Steps Involved in Elicitation of Requirement:

  • Requirement inception: Relates to the use of context free questions
    • To establish the basic understanding of the problem,
    • To understand the people who wants the solution,
    • To understand the overall nature of the solution expected,
    • To gauge the effectiveness of the collaboration between customers and developers.
  • Requirement Identification: It Involves
    • Enlisting the basic well known and fairly defined needs
    • Articulating the basic well known and fairly defined needs
  • Requirement elicitation: Refers to finding out or extracting from the clients/ users
    • Requirements which are unclear, vague, or concealed and need explicit articulation for the understanding of the developer team.
    • About what the overall product/solutions objectives are.
    • About which needs are to be supported on priority.
    • About how the product / solution fits in to the business needs.
    • About what kind of use will be made of the product/solutions on day to day basis.

Quality Requirement Elicitation

Quality Requirement Elicitation:

While Gathering requirements, attention should be paid to ensure that quality requirements are gathered during the elicitation process. Every requirement should confirm to the following quality norms:

  • Correctness – The correctness of the requirement should be confirmed with the client’s stakeholders.
  • Feasible – The requirement should be deliverable by making use of available tools, technique, method and people, within budget and time.
  • Necessary – With respect to undertaking, the development and immediate implementation for meeting the basic needs of the client, the ranking of the feature should be of relatively high importance.
  • Prioritized – With respect to priority scale, the ranking of the feature should be one of relatively high importance.
    • Requirements, if very important, should be immediately included in the present release of the proposed system.
    • Requirements, if absolutely necessary should be essentially implemented in the next release.
    • Requirements, if important but not necessary, should be conditionally included in next release.
    • Finally, requirements if purely optional, their implementation should depend upon the constraints of the resources and schedule.
  • Unambiguous – The requirement should be easy to read and understood by all.
  • Concise – The requirement should be brief or short or to the point with only the relevant information. It should be mixed up with other details related to project scope parameters or background.
  • Verifiable – The implementation of the requirements in the end product or software deliverable should be testable and measurable by human or mechanized means.

Requirement election methods – Interview

Requirement election methods – Interview

Interview – Interviewing is the most commonly used requirement elicitation technique used usually in conjunction with almost all of the other method. It involves the following steps described in detail as under.

  • Creating questions – Firstly, this step involves taking the inputs from project documents to seek background information. Next, it involves the preparation of relevant set of questions which will be able to uncover knowledge and reveal true requirements on what is needed, rather than what is wanted or thought to be needed. All questions and answer should be documented so it can be use for future analysis.
  • Selecting Interviewees – This involves identification of representative from stakeholders groups based on their background. The entry level personnel often provide fresh perspective and unexpected pearls of information. The mid-level stakeholders provide useful insight into the operational or technical aspect of the domain due to their experience. The managers or special customers, having deeper knowledge of domain and understanding of the success project criteria so they provide valuable input which is vital. The varied backgrounds of the stakeholders provide help in verifying the reliability of collected information.
  • Planning Interview session – Before planning the sessions, a background check of each of the representative stakeholders is useful. It provides an understanding of each individual’s personality, orientation, contribution, achievements and stake in the project. Main focus should be on identifying oneself, clarifying purpose, indicating process by which the interviewee was chosen. Emphasizing on need for face to face discussion, contact details should be conveyed to facilitate interviewee to revert back in case of any problem requiring reschedule of the session.
  • Closing meeting – care should be taken before closing the meeting to keep the morale of the interviewee high so that cooperation could be sought in future too. Before concluding the interview, it should be inquired if the interviewee has any questions. Any documents or artifacts, copies of which could be needed for further analysis.
  • Planning Future course of action – Follow up action, by formally thanking the interviewee for his/her participation should be sent as soon as possible after the interview. The findings should be properly documented. Future Planning for requirement specification.

 

Requirement election methods – Brainstorming

Requirement election methods – Brainstorming

Brainstorming is a technique, which involves a group of people during the requirement gathering process. This method is adopted for various purposes such as for defining the problem to be solved, arriving at the requirement specification, analyzing and modelling the requirements and evolving the design of the software to be developed.

It involve following steps

  • Roles – Normally participants are categorized as per their roles.
    • There is a leader designated for the entire group who act as a facilitator or moderator. He is the person who defines the agenda, sets the brainstorming session rolling, encouraging, motivating and leading the discussion.
    • There is a person designated as a scribe, who records all ideas in a manner visible to all using flip charts, white board, transparencies or computer presentation.
    • There are participants, usually limited to less than ten persons, representing the stakeholders who voice their ideas, listen to others.
  • Rules – Various rules are usually framed for the collection of the brainstorming session, depending on the roles of the participants.
    • The leader should allow all ideas to be expressed freely without criticism, prevent judgement, establish decorum, set time limits, and establish focus on purpose.
    • The scribe should capture essence of ideas – not descriptions, write ideas in short summaries form as stated, seeking clarification if required.
    • The participants should contribute their own ideas – not picking a lead form of others. They should be creative, imaginative and apply fast thinking.
  • Guidelines – Various guidelines have been proposed by experts to ensure the success of brainstorming sessions such as
    • Allowing group members to decide on breaks, arranging for refreshment, setting the mood for the session right using light humor at the beginning, restricting the session for two hours.
    • Creating trust and report for letting creative ideas being freely expressed while session.
    • The essential project document and rules of the session should be made available to all participants well in advance.
  • Agenda – The agenda for brainstorming session could be on the following lines.
    • First the purpose and objective of the session should be made clear to all, explaining the rules and introducing all participants.
    • This should be followed up by a warm up activity of around 10 minutes to establish the right mood for all participants on a topic commonly understood by all but unrelated to agenda.
    • After this, the actual brainstorming activity should commence. Ask participants to quickly come up with ideas in relation to finding ways of solving problems in line with ideas in relation to finding ways of solving problems in line with the core purpose and objectives. After an intensive session of 10 to 15 minutes call for a break before resume once again.