One of the most important phases of the Software Development Lifecycle is the Requirement Phase. In fact it is so important we start the software development lifecycle by creating a requirements document. This document effectively creates a foundation on which our software will be constructed. By Creating a System Requirements Specification document that is both detailed and descriptive we can ascertain requirements and expectations to fulfill the client’s needs.
Creating the System Requirements Specification document is a four phase process. Below covers the four phases and briefly describes each phase:
- Feasibility Study:
- Understand the clients’ needs and expectations
- Develop feasible features to aid them in their goals
- Can the client afford the development of specific features?
- Is the cost worth the value of said specific feature?
- Will the feature require constant maintenance?
- Will the feature be easy for the user to utilize?
- Will the feature increase productivity?
- Does this feature need to be integrated into any other systems currently being utilized by the client?
- Requirement Gathering
- After discussing the feasibility of the features with the client, engineers and analysts will button down exactly what the client expects of the software.
- Functional Requirements: a function that a system or component must be able to perform. (Functions, Inputs, Outputs, etc.)
- Non-Functional Requirements: Expectations of how the software performs. (Speed, Size, User-friendliness, Reliability, Robustness, Portability)
- Domain Requirements: Document the functions that is required which may hinder the functionality of the software if not properly implemented. More plainly they are industry specific technical requirements. (max air pressure of a respirator)
- After discussing the feasibility of the features with the client, engineers and analysts will button down exactly what the client expects of the software.
- Software Requirement Specification
- After the requirements are collected and documented a Software Requirements Specification document is developed.
- The Software Requirements Specification document defines how the software will interact with the hardware.
- Operating Speed, Response Time, Maintainability, Cross-Platform Support, Recovery Time, Security, Limitations, etc.
- This document takes the expectations of the client and refines the requirements into a more technical internal document utilized by the development team.
- Pseudo code, format, and GUI screen shots help more fully detail the technical expectations for the development team.
- Software Requirement Validation
- This step takes all the information that was gathered and validates if the expectations are practical, correctly understood and within the domain guidelines.
Elicitation Process
Before we begin developing software we should research any similar systems that are already in existence. In this way we can see different structures as well as benefits and shortcomings of said systems. This valuable insight can save time, cut costs, and offer a better experience for users. There are many elicitation methods to utilize in our research; throughout this paper I will discuss three elicitation methods as well as their benefits and disadvantages.
- Interview Method
- In the interview method the person conducting the interview may have a structured set of questions for the person being interviewed or it may be unstructured to allow the interviewer more freedom for open discussion.
- In either case it is most effective to ask predominantly open ended questions to avoid short answers.
- Benefits of the Interview Method:
- Builds relationships with clients
- Immediate feedback to insure comprehension
- May get answers for questions you didn’t think to ask
- Disadvantages of the Interview Method:
- Requires time to be set aside from both interviewer and interviewee
- An interview can become mechanical and could potentially hurt the relationships you are trying to build.
- Both interviewer and interviewee need to be invested in the interview process. The interviewer needs to ask substantive questions and keep the interview on track and the interviewee needs to give applicable and essential answers and feedback.
- Brainstorming Method
- In the Brainstorming Method a group, often consisting of experts in their respective fields, offers their expertise to get valuable insight into the project.
- Benefits of the Brainstorming Method:
- Immediate feedback from group members
- The Brainstorming Method fosters creative insights.
- Disadvantages of the Brainstorming Method:
- If not properly managed it can devolve into a debate instead of an open communication of ideas.
- Interface Analysis Method
- In the Interface Analysis Method we take a closer look at what interfaces will be needed between components within our software. To do so we find out how the system will be used, this will help us know what data needs to be exchanged between components.
- Benefits of the Interface Analysis Method:
- Can drastically simplify your software
- Answers questions that the other elicitation methods may not cover
- Disadvantages of the Interface Analysis Method:
- The Interface Analysis method focuses solely on the interface, all though this can be of great use it should not be the only method used.
Researching a project on its inception is in my opinion the most important step in the Software Development Lifecycle. Utilizing multiple elicitation methods can help us get as much information in the shortest amount of time. The advantages of one method can compensate for the downfalls of another. Often times when teams are eliciting and analyzing the requirements of the project issues may arise. Commonly these issues are from a lack of communication between the analyst/engineer and the client/stakeholders and conflicting views on the requirements of the system. The third common problem teams may encounter is ever evolving requirements. That is why I have chosen two methods that interact closely with experts in their respective fields. First to gain information in the interviews; then to have an open discussion where we can foster a creative exchange of ideas and iron out any conflicting expectations. All of these problems can push a project over budget potentially damaging a company’s reputation and the relationships it’s working to foster.
Now that we have a more complete understanding of the Requirements Phase of the Software Development Lifecycle we can see that before we begin developing the software we need to understand fully what the expectations are, what problems we are trying to solve, and any technical industry specific information that needs to be implemented. The hardest part of developing specialized software for industries outside of your expertise is often we don’t know what we don’t know. This is why taking plenty of time to fully discuss the needs of the client is so important. Any detail left out could potentially be catastrophic; resulting in loss of money, legal liability, or potentially even loss of life. Often times we see companies looking for employees who have both experience in and outside of the software industry. This is especially true in the medical industry; to have a software engineer or analyst who has experience working in hospitals or pharmaceuticals can be a huge boon to successfully creating software that meets and potentially exceeds expectations in a fraction of the time.
References
Software Engineering | Requirements Elicitation (2020). Retrieved from: https://www.geeksforgeeks.org/software-engineering-requirements-elicitation/
Top 10 Most Common Requirements Elicitation Techniques (2021). Retrieved from: https://www.softwaretestinghelp.com/requirements-elicitation-techniques/
Software Engineering | Challenges in eliciting requirements (2018). Retrieved from: https://www.geeksforgeeks.org/software-engineering-challenges-eliciting-requirements/
