In This Chapter we tackle about requirement
discovery. I've learned a lot in this chapter like the definition of
Requirement Discovery is the process and techniques used by systems analysts to
identify or extract system problems and solution requirements from the user
community and System Requirement is something that the information system must
do or a property that it must have. System Requirements also called business
requirement. If your requirements are incorrect the results would be the system
may cost more than projected. The system may be delivered later than promised.
The system may not meet the users’ expectations and that dissatisfaction may
cause them not to use it. Once in production, the costs of maintaining and
enhancing the system may be excessively high. The system may be unreliable and
prone to errors and downtime. The reputation of the IT staff on the team is
tarnished because any failure, regardless of who is at fault, will be perceived
as a mistake by the team. There are Several Criteria to define System
Requirements one of those criteria is to make your requirement be Consistent,
Complete, Feasible, Required, Accurate, Traceable and Verifiable.
Discovering exactly what users, stakeholders, and sponsors want you to
create is often the most difficult part of an IT project. Communication between
IT experts and nontechnical clients can be fraught with misunderstanding and
misinterpretation. As I discussed in previous columns, users often don't know what they want until they see
it, and they frequently can't articulate
their expectations in language that IT experts use to design systems.
Technicians often frame their requirements questions in technical language, such as, "Must it work in a browser?" or "How will the data be validated?" and clients may not have the technical background to respond to these questions. Users often explain their expectations in vague language, such as "fast" or "responsive," which lack the specificity designers need to develop solutions.
If you have a problem with your requirements try to use the Ishikawa diagram. Ishikawa diagram is a graphical tool used to identify, explore, and depict problems and the causes and effects of those problems. It is often referred to as a cause-and-effect diagram or a fishbone diagram this would be a very big help in terms of your problems. In requirements discovery we also considered the fact-finding or the formal process of using research, meetings, interviews, questionnaires, sampling, and other techniques to collect information about system problems, requirements, and preferences. fact finding are also called information gathering or data collection.
There are Seven methods in Fact
finding those methods are sampling of existing documentation, forms, and
databases, Research and site visits, Observation of the work environment, Questionnaires,
Interviews, Prototyping and Joint requirements planning (JRP). This following
fact finding methods or strategies could be a big help in the requirements
discoveries because this methods provide data that could be useful in the
project. It also provides information on what is the need of the consumer.
In
requirements discovery I also understand the concept of requirements management
which the process of managing change to the requirements. I also considered the
Sampling which means that the process of collecting a representative sample of
documents, forms, and records. in Sampling there are techniques such as
Randomization a sampling technique characterized by having no predetermined
pattern or plan for selecting sample data and Stratification a systematic
sampling technique that attempts to reduce the variance of the estimates by
spreading out the sampling like choosing documents or records by formula and
avoiding very high or low estimates there are more techniques like observation
, interviewing , questioning and work sampling to solve or fix our requirements.
User stories connect with the philosophical threads of agile methods by reminding us that we don't need formal templates or special graphical languages to have a conversation with the customer about what they want. User stories reinforce the "barely sufficient" mindset that keeps us from being diverted into low-value administrative tasks. Most importantly, user stories help us stay engaged with the customer throughout the project, and require that the customer do so as well. The conversations that ensue from that collaboration are the core of agile engagement.
I've just grazed the tip of the iceberg regarding user stories. In future columns, I'll discuss using user stories to estimate the project, and explain how stories can be used to keep the sponsor informed and educated about the project status and progress.
