Requirement Engineering: Challenges, Techniques, and Tools, Exams of Information Systems

Download Requirement Engineering: Challenges, Techniques, and Tools and more Exams Information Systems in PDF only on Docsity!

Chapter 4:

Requirement engineering

Learning outcomes:

Explain system requirements and the challenges associated with the requirement engineering process

Differentiate functional and non-functional requirements

Discuss team-based requirements engineering techniques, JAD, RAD and agile

Identify a fact-finding plan for gathering requirements

Define what is an interview for gather requirements

Explain other requirement gather techniques such as document review, observation, questionnaires, surveys,

brainstorming, sampling and research.

List how requirements are gathered in agile projects

List different requirement representation techniques

Define what is it to verify and validate requirements

List what tools can help with requirement engineering activities

Team based techniques

Joint Application Development

(JAD)

Rapid Application Development (RAD) Agile Methods

Fact finding technique that brings users into the development process as active participants. End product – requirement model Speeds up IS development and produces a functioning IS. Continuous process. End product – information System Built incrementally with prototypes and constantly adjusting to user requirements. Must learn from the previous steps Doesn’t use CASE tools but whiteboard and sticky notes. FOCUS is to be simple, rapid, flexible and user orientated Users are formally or informally involved in every stage of SDLC Users review prototypes early on, evolves with changes to final product Relies on prototyping and user involvement Day/Week session, no interference, focus just on meeting. Reduce cost & development times – increase productivity of success There is a facilitator, scribe. Members are there to debate and agree Group approach There is an agenda Complete methodology – 4 phases

• Requirement planning – planning and analysis, team discuss and agrees on requirements = authorisation to continue
• User design – user and SA develops input, output and processes. Continuous interactive process for users to understand, modify and approve working model.
• Construction – development tasks of SDLC. User still participate and suggest changes
• Cutover – final phase of SDLC (implement, test, training, handover) Scrum (agile approach) – just like in rugby Expensive, cumbersome if group is large Stresses the mechanics of the system, does not emphasize strategic business needs, work well short term but not long term. Development so quick, sacrifice quality, consistency, design standards. Need high level of technical and interpersonal skills Blur lines of roles and responsibilities Loss of corporate knowledge Overall project can change as user requirements continue to evolve Users participate, feel sense of ownership, generate support. Accurate requirements, better understanding, stronger commitment Developed quickly but inexpensively Adaptable, flexible and efficient in dealing with changes. Stress team interaction and reflect a set of community- based values Frequent delivery constantly validates the project and

Gathering requirements AKA Requirement elicitation/fact-finding (3 themes: what, how, what) SA develops a fact finding plan that answers questions like who, what, where when and how. SA needs to understand the business and its environment before asking such questions

Interviews Document review Observation

Planned meeting Steps

1. Determine the people to interview
2. Establish objective for the interview
3. Develop interview questions – avoid leading questions (open end (any answer) or closed end (short given answers))
4. Prepare for the interview
5. Conduct the interview
6. Document the interview
7. Evaluate the interview Reviewing of existing document, however, can be outdated or non-existent if previous SA didn’t document the system Also look at vendor documentation if you bought the software Seeing the system in action Validates statement from interviews or documentation to the real system Can help build relationships with users Can be a positive or negative thing for the user

Questionnaires / surveys Brainstorming Sampling

It is asking many people a standard set of questions People can be anonymous Can use software like Google Forms or Survey monkey that can capture the questionnaire answers You wont get detail thru a questionnaire Questions can be misunderstood/misinterpreted Targeted at a small number of people Makes people interact (participate) to build new ideas and on each other Structured – person talks when it is his/her turn Unstructured – talk any time Results are recorded and documented Examples of actual documentation Systematic – to balance sample (take every 10th^ one) Stratified – select x number from x areas Random – selecting randomly Used for interviews and questionnaire Research – reviewing documentation like magazines or doing site visits

Validating and Verifying Requirements Demonstrating that the requirements defined the system that the customer really wanted. Validation – Are the correct requirements stated? Verification – Are the requirements stated correctly? Tools To record and document requirements = productivity software (word, excel, access, etc) Calendars, to do list, contacts = personal information manager Using MS Office is very useful to present requirements (documentation such as reports, presentations, etc) MS Office – Word, Excel, Access, Project, Visio, Outlook, Onenote, Teams, Powerpoint, etc) There is also software out there that can draw models like UML – traceability, Sybase, etc.

Conclusion

System requirements and the challenges associated with the requirement engineering process is listed and

explained

Functional and non-functional requirements are identified

Team-based requirements engineering techniques, JAD, RAD and agile are tabled

A fact-finding plan for gathering requirements is identified

An interview for gather requirements is defined

Other requirement gather techniques such as document review, observation, questionnaires, surveys,

brainstorming, sampling and research are tabled (identified)

How requirements are gather in agile projects is listed

The different requirement representation techniques is listed

What is it to verify and validate requirements is identified

What tools that can help with requirement engineering activities is mentioned.