chapter3 requirement analysis.pdf

ISYS-1117

ISYS1117 Home page What is a requirement?

"Confidence in nonsense is a requirement for the creative process." --Unknown

n a normal software engineering scenario, a project goes through the

following steps:

● Planning ● Requirements Analysis ● Requirements Specification ● Systems Design ● Software Implementation ● Software Testing ● Software Release and ● Software Maintenance

Table Of Contents

1.0 - Requirements Analysis - Prelude 1.1 - What is a requirement2.0 - Requirement scenarios3.0 - Fact finding techniques 3.1 - Interviewing 3.2 - JAD 3.3 - JAD & Questionnaire4.0 - Specification & SRS 4.1 - SRS5.0 - Functional vs Non-functional requirements6.0 - Specification Review7.0 - References & Acknowledgments

There is no definitive length or time-frame fixed or defined for these activities. Depending upon the project length, its scope and project-deadlines-these activities take their shape. It is equally possible that these activities might overlap. It is, however, important to realise that some activities among above have more weighting than others. Requirements Analysis is one such activity which is one of the most crucial. Requirements Analysis is the process of gathering information about the current system or the system under analysis. The system might or might not be computerised. In the Requirements Analysis stage, one outlines the strengths and weaknesses of the system. After understanding the requirements of the system, it can be decided whether a new system is required or not. Under a broader picture, it can be divided into some smaller steps:

● Understanding the sysytem ● Identifying improvements and

https://inside.cs.rmit.edu.au/~laura/se/index.html

https://inside.cs.rmit.edu.au/~laura/se/online/chapter3/chapter3.pdf

● Developing the concept of the new system (if needed)

These three steps are highly cohesive and iterative. This is the 'real secret' behind a good software requirement practice. Thus, a real analyst would always flip back and forth between information gathering and analysis. Based on that, an analyst would suggest implementations. Sometimes some other terms are associated with the above steps. In particular the following three terms are really substantial.

Elicitation

In elicitation one should identify the users requirements. Analysis

Here one should analyse and develop this information to create an unambiguous picture of the system to be built.

Specification Stage

This involves the thorough documentation of the scenario through reports and models.

Another important term used it system. Now what is a system?

A system is a set or arrangements of elements that are organised to accomplish some pre-defined goal by processing information. Software, hardware, people, database, documentation and procedures all constitute what is known as the components of a system. It is important to understand that even if a system is a non-trivial system, its needs must be specified.

For instance, one can state that a bridge must support at least 1,000 tons, must be 30 metres wide, etc. In that sense, the specification is a precise statement of the requirements of that system. Thus we can say that a Requirements Specification is an agreement between the end user and the system developer.

Before going ahead it is important to know that REQUIREMENTS can be broadly classified into two categories:

● Functional requirements are those that relate directly to the functioning of the system.

● Non-Functional requirements are those which cover aspects of the system such as user-interface, performance, quality issues, interfaces to other systems, and security.

We shall cover these later in more detail.

Checkpoint1. What is the difference between Software Elictitation and Software Analysis? 2. One of the major components of the requirements analysis study is to outline a clear cut picture of 'specifications'. As said earlier, Requirements Specification is an agreement between the end user and the system developer. One should keep in mind the fact that these specifications must be consistent. Suppose you were asked to define the specifications of a software system that your team is going to first conceptualise and then build. Suppose this software is nothing but a word processor. Can you define two consistent software specifications for such a system.

ISYS1117 Home page What is a requirement?

ISYS 1117 - Software Engineering Analysis and DesignOnline Tutorials

Copyright © 2002 RMIT Computer Science

All Rights Reserved

https://inside.cs.rmit.edu.au/~laura/se/index.html

http://www.cs.rmit.edu.au/


ISYS-1117

Requirements analysis - Prelude Requirement scenarios

Before we go into detail of why Requirements Analysis is required it is important to first define what a Requirement is.Every system development process begins with an initial list of user needs, identified problems and/or directives. These are nothing but the requirements of the system. A Requirements Definition Document is a list in simple language of these functions and constraints.

Table Of Contents


Furthermore, Requirements Analysis is the process of sitting down and thinking carefully about what your system should be able to do. Consider an example from your day-to-day scenario - Starting with looking at your personal requirements, this essential first step of buying a PC lays the foundation for looking at the PC's requirements, and then of course, determining the characteristics of the equipment that will fulfill these needs. Planning and analysis activities are considered by many to be dry and uninteresting compared to getting 'hands on' and playing with the hardware. Or even better, actually buying something and getting to take it home and plug it in! However, it is absolutely essential that this first step is not skipped over. Let us look at some of the requirements analysis that you need to go through before you actually buy a PC.

● Do I actaully need to buy a PC? ● Which one should i buy-the branded one or the assembled one? ● Which ones are more popular? ● Well, I have to do that requirements vs price tradeoff analysis as well. ● Or should I buy a notebook instead of a desktop PC? ● Will I get warranty?

Now these are some of the questions that might rock someone's mind. It is important to

see that such an analysis at the inception stage of a project is very important for its later success. Be it a large or small project, one from your daily live - requirements analysis is essential.

How we do go about the process of requirements analysis and elicitation?

Over many decades, investigators have identified analysis problems and their causes, and have developed a variety of modeling notations and corresponding set of heuristics to overcome them. Each analysis method has a unique point of view. However, all the analysis and elicitation methods are related to a set of the same operational principles. These are:

● The information domain of a problem must be represented and understood. ● The functiosn of the system/software to be bulit must be understood. ● The behaviour of the system also needs to be analysed. ● The analysis process should move from essential information towards

implementation details.

By following these principles, analysts approach towards a system systematically. One of the very famous analysts, Davis, suggested a requirements engneering approach that states:

● Understand the problem before you begin to create the analysis model. ● Develop prototypes after you have outlined the basic requirements of the system. ● Record the origin and reason of every requirement. ● Use multiple views of requirements. ● Prioritize requirements. ● Work to eliminate ambiguity.

Thus we can see that, although there are different theories, they all follow the same path.

Requirements analysis - Prelude Requirement scenarios



All Rights Reserved



ISYS-1117

What is a requirement Fact finding techniques

et us look at some practical scenarios. This is an outline of the

requirements analysis done by a HUMAN RESOURCE company.

Table Of Contents


Look at this diagram

This image is a copyright of http://www.manningaffordability.com/S&tweb/HEResource/Process/S2PD.htmLet us now look at some classical mistakes that an organisation/people might make to avoid a detailed Requirements Analysis:

I wont require this analysis stage because... You will require it because...

The management objection: We have done a management survey/brainstorm and we know what we want.I'm a manager and I'm in the business for 20 years. I know what the user needs.I'm a user, I know what I need.Who cares about the requirements analysis and eliciation stage......

What managers in the developing company think the website should offer, is certainly interesting information, but these managers are not the future users. What they want on the site is not (necessarily) what users want on the site. What managers know about future users is what they need to know for their job. Since their job is not designing websites, they probably don't have the kind of knowledge about users that is needed to design interactive systems.

The creator's objection: We have a team with great ideas, creative concepts, powerful technologies. Surely they can design a great system. So who cares about the requirements analysis and eliciation stage......

Creativity and technology provide solutions. We still need to solve a real problem with this solution or it will not be used. Do you want to design a product that the creators think is great or a product that users think is great?

The budget objection: We don't have the budget for user requirements analysis.

The cost of learning something about users you didn't want to know at the start of a web project, is small compared to the cost of learning it after launching the website.

The planning objection: It doesn't fit in our planning. We want to launch our website in 2 months.

User requirements analysis can be scaled to the size of the project. It's better to do a 5-day analysis than no analysis at all. User requirements analysis should be planned from the beginning of a project. Time-to-market is less important than being in the market with a product that is used by users. First mover advantage is often misunderstood. You don't create a first mover advantage by launching a website. It's the user who creates the first mover advantage by using your site. If s/he doesn't, no advantage.

The novelty objection: What we're developing is something completely new. There's nobody to analyze. We don't care how people currently work. We're going to provide a new way of working with the system.

If your system is so new that nothing is related to it, there's a big chance that nobody will understand nor use the system. If users can't relate to your product, you probably don't have a market. If you don't know the current way of working, how will you know whether the new way is more effective? Are you sure you will not create new problems with the system? On what are you going to base design decisions for the new system if you don't know the current way of working?

The academic objection: User requirements analysis sounds like academic research. We're not at the university. We're a company developing a website.

User requirements analysis uses some techiques derived from social science research. However, it is not like scientific research in its goals nor the way it is conducted. User requirements analysis is entirely focused on designing effective interactive systems. It does not pretend to answer research questions beyond that goal. In addition, timing and costs of the analysis are reduced to meet development demands.

Checkpoint1. What are some typical mistakes an organization might commit while analysing requirements?2. A developing team member argues-"...Instead of analyzing user requirements, we will make a prototype and test that with users." How will you counter-argue them?

What is a requirement Fact finding techniques



All Rights Reserved



ISYS-1117

Requirement scenarios Interviewing

Where facts are few, experts are many. --Donald R. Gan

o implement the plan, the analyst needs to gather the right

information.While gathering information, an analyst should look at all the possible clues and should try to gather as much information as he/she can. There are various fact finding techniques that an analyst can adopt-some of them being:

■ Looking into documents ■ Interviewing ■ JAD ■ UML approach such as Use-cases ■ Questionnaires, Observations,

Sampling

Table Of Contents


Fact Finding Techniques

Lets us now look at some of these.

Interviewing

"Any fact facing us is not as important as our attitude toward it, for that determines our success or failure." - Norman Vincent Peale

An Interview is one of the most important and basic techniques to gather information. Normally they are conducted one-to-one , but sometimes group interviews might also be held. But before interviewing it is important for the analyst to make sure they are interviewing the right people. In order to know that, it is important to clearly outline all the key stakeholders of the intended

system. Thus some important steps would be:

● Selecting interviewees ● Desigining the Interview questions ● Preparing for an Interview ● Conducting the Interview ● Follow-up

One should start with creating an interviewing schedule. This should list all the interviewees along with the time and purpose of their Interview. It is very important to have a clear opinion on who is going to be interviewed. This can be crucial to the success of the project. As an example, MICROSOFT, before even launching any new product, undergoes a massive interviewing session with a lot of target end-users. This gathers a lot of information, even before they have embarked upon a project. This gives them a cutting edge over their competitors.

While Interviewing the right people, analyst can come up with more ideas and some facts that have reamined latent even during the preliminary stages of requirements elicitation phase.

The next important step is how to design interview questions?Normally the questions fit three categories:

● Open-ended questions: questions that leave room for elaboration on the part of the interviewee.

● Closed-ended questions: questions which require a specific answer such as YES or NO. ● Probes: are the ones that follow up or supplement the above questions, asking for more

detail.

Let us examine those in a bit of detail.

Open-ended questions are questions to which there is not one definite answer. Open-ended questions may be a good way to break the ice with a survey, giving respondents an opportunity to answer in their own words. Example: "Are there any other comments about the course you would like to add?" The responses to open-ended questions can be very useful, often yielding quotable material. The drawback to open-ended questions is that the responses are more difficult to catalogue and interpret.

Closed-ended questions have a finite set of answers from which the respondent chooses. One of the choices may be "Other." It is a good idea to allow respondents to write in an optional response if they choose "Other." The benefit of closed-ended questions is that they are easy to standardize, and data gathered from closed-ended questions lend themselves to statistical analysis. The down side to closed-ended questions is that they are more difficult to write than open-ended questions. This is because the evaluator must design choices to include all the possible answers a respondent could give for each question.

Requirement scenarios Interviewing



All Rights Reserved



ISYS-1117

Fact finding techniques JAD

et us now look at some types of closed-ended questions:

There are five basic types of closed-ended questions to choose from. Each one is briefly explained below, with examples provided:

Table Of Contents


1) Likert-scale: When you want to know respondents' feelings or attitudes about something, consider asking a Likert-scale question. The respondents must indicate how closely their feelings match the question or statement on a rating scale. The number at one end of the scale represents least agreement, or "Strongly Disagree," and the number at the other end of the scale represents most agreement, or "Strongly Agree." If the scale includes other words at either end to further clarify the meaning of the numbers, it is known as a Likert-style question. Example:

How important do you think standardized test scores are to a fifth-grader's education (circle one number): Not very important Extremely important 1 2 3 4 5

2) Multiple-choice: When you want respondents to pick the best answer or answers from among all the possible options, consider writing a multiple-choice question. Multiple-choice questions are easy to lay out on a written survey. Include specific directions about how many answers to select directly after the question. Example:

Why don't you use the school's cafeteria services? (circle one): a. It's too expensive. b. Serving times conflict with my class schedule. c. The location is inconvenient. d. The food quality is poor. e. Other (please explain):_______________

3) Ordinal: When you need all possible answers to be rank ordered, ask an ordinal question. Example:

Please write a number between 1 and 5 next to each item below. Put a 1 next to the item that is MOST important to you in selecting an on-line university course. Put a 5 next to the item that is LEAST important. Please use each number only ONCE. ___ a. Availability of instructor for assistance. ___ b. Tuition cost for the course. ___ c. Ability to work in groups with other students. ___ d. Quality and quantity of instructor feedback. ___ e. Number of students enrolled.

4)Categorical: When the possible answers for a question are categories, and each respondent must "belong" in exactly one of them, ask a categorical question.

5)Numerical: When the answer must be a real number, ask a numerical question. Example: How old were you on your last birthday?

How do I know which type to use?

Type of question Best Used for... Open-ended Breaking the ice in an interview; when respondents' own words are important; when the surveyor doesn't know all the possible answers. Closed-ended Collecting rank ordered data; when all response choices are known; when quantitative statistical results are desired. Likert-scale To assess a person's feelings about something. Multiple-choice When there are a finite number of options (remember to instruct respondents as to the number of answers to select). Ordinal To rate things in relation to other things. Categorical When the answers are categories, and each respondent must fall into exactly one of them. Numerical For real numbers, like age, number of months, etc.

Fact finding techniques JAD



All Rights Reserved



ISYS-1117

Interviewing JAD & Questionnaire

AD is a structured process in which 10 to 20 users meet together for several hours, days, weeks or months under

the direction of a skilled facilitator. This technique was developed by IBM in 1970s. It is often a very useful technique for collecting information from the user. The aims of a JAD session are the following:

Table Of Contents


● To identify the problem, propose elements of the solution and negotiate different approaches to the problems uncovered.

● To develop an initial set of user requirements in an atmosphere that is conducive to the accomplishment of the goal.

So why do I need to know about JADs? ● Ask your client what they want. ● Client signs off on specifications. ● You build and deliver the system according to the specifications. ● Your client says they want something different.

How do you design a system that clients really want? You can't. You have to help clients design the system they want. If you are telling business users how to solve their problems, you are missing the boat. You have to establish a relationship with the client to get behind what they are saying the problem is in order to discover the true underlying problem.

The real problem is typically very different from the one first perceived by the client. Don't just be a problem solver...look deeper. Don't assume that one person ever knows everything about a problem.

What is a JAD?JAD Definition: Joint Application Development (JAD) is a management process which helps IS work effectively with users to develop information technology solutions that really work.

JAD Purpose: to define the project, design a solution, and monitor the project until it reaches completion.

JAD Philosophy: The JAD process is based on four simple ideas:

1. People who actually do a job have the best understanding of that job.

2. People who are trained in information technology have the best understanding of the possibilities of that technology.

3. Information systems and business processes rarely exist in isolation -- they transcend the confines of any single system or office and effect work in related departments. People working in these related areas have valuable insight on the role of a system within a larger community.

4. The best information systems are designed when all of these groups work together on a project as equal partners.

JAD Scope - The JAD should cover the complete development life cycle of a system. The JAD is usually a 3 to 6 month well-defined project. For large-scale projects, it is recommended that the project be approached incrementally, and that separate JAD's be used for each increment.

Who is involved in a JAD?Sponsor - this is the executive who charters the project, the system owner. They must be high enough in the organization to be able to make decisions

and provide the necessary resources and support for the project.

Business Users - the intended users of the system being designed. They are here because of their business expertise. There are two kinds of Business Users; Real End Users and Big Picture Users.

Real End Users will have to use the new system to do their jobs. Big Picture Users understand the standards and methodologies of the business functions. It is important to have both types of users. If you only have Big Picture Users you will end up with a great theoretical model of how things should work, but it may not work in practice. If you just have Real End Users, you will get a good system for today, but it may not work a year or two down the road.

Systems Analysts - Provide non-technical explanations that help other JAD members understand and fully utilize the technology available. Monitor design for ease of use/maintenance and adherence to standards. Provide hardware/software development.

Important Question to Ask: Do I have all the affected customers/areas represented?

Roles of JAD Group MembersProject Sponsor - remember, this is the person who owns the business process. Their support and participation is crucial to the success of the JAD. In addition to the project responsibilities listed below, the project sponsor and the lead analyst can share the role of Project Leader, being equally responsible for the successful completion of the JAD.

Project Sponsor Responsibilities

● ensure the right clients are part of the group ● ensure there is enough technical staff support for the

project ● ensure that software/hardware is purchased as needed

for the project ● ensure that the clients are given time off from their

regular work to attend the JAD meetings and to perform the tasks they are assigned by the JAD

(policy research, gathering information / opinions from other client groups, documentation, testing)

● assign and work on policy research ● delegate tasks to clients who are in the group ● ensure that the client tasks are done ● assist in the selection of test cases ● assist in the definition of the scope and functionality ● assist in benchmarking against current systems and

external systems ● help set up quality measures ● evaluate whether the system is effective and efficient

Project Leader - the project leader can make or break the project. They need to be committed wholeheartedly to the project, and to have a background knowledge of the business area and current or related information systems. They also need to be committed to the company, and to understand the implications of the project within the context of company goals. They need to be enthusiastic and objective. They need to be sensitive to political issues and able to draw out the opinions of the quiet members of the group, and to not allow any single individual to dominate the group.

Project Leader Responsibilities

● work with project sponsor to ensure the right people are in the group

● ensure all roles for the group are filled ● ensure that meetings are scheduled and publicized

with agendas ● ensure that agendas are planned and followed ● ensure that meeting notes are taken, and published by

the recordkeeper ● edit the notes and make sure they are not a transcript

but a concise accurate summary of decisions made (both pro and con) and issues discussed and actions to do (make sure they are available historically if a new member has to join in the middle of a project)

● ensure that tasks are assigned and done, and that a task list is planned and executed in the sequence that it needs to be, with appropriate timelines

● coordinate the technical efforts of the analysts on the team

● do research prior to the meetings to make sure background information is gathered on the appropriate agenda topics

● facilitate the meetings effectively

Recordkeeper - The recordkeeper takes comprehensive notes during a session, and then edits them into a concise summary of discussions and decisions. It is important that the resulting notes NOT be transcription of who said what. The role can be shared by various members of the team as needed. Often a well-facilitated meeting will have a note taking recordkeeper, and also someone who records points on an easel pad. The easel pad serves as a ready reference to the group when summarizing discussions, and for return reference on complex points. And it also is a means for the recordkeeper to evaluate the accuracy and thoroughness of their notes.

Recordkeeper Responsibilities

● take accurate and thorough notes during the meeting ● ask for clarification on points if anything is not clear ● summarize and condense the notes after the session ● ensure that the JAD leader and project sponsor or

other relevant people proof and edit the notes prior to publishing

● publish the notes for all current members of the team and for any other interested parties

● keep a history of the notes for the benefit of any members who join the team in mid-project

● remind the group if they contradict earlier decisions and make sure they know they are in contradiction.

Timekeeper - The Timekeeper is responsible for keeping the meeting running on time and helping the group use time wisely.

Timekeeper Responsibilities

● makes sure the meeting begins and ends on time● helps the meeting stay on time for each topic on the

agenda● reminds the group that they need to end a discussion

in order to have time to summarize and create an action plan in the final minutes of the meeting

Clients - Clients are here because this is a system they use. They understand how this system is used in the real world. They will help the group understand all the tasks handled by the system, correct any misperceptions, search for oversights and supply details. Remember, no detail is too small to mention. Sometimes minor details make a major difference in the way the system should work.

Typical Client Responsibilities

● describe the sequence of events in a business process as it affects their office

● describe the decisions that have to be made in a business process

● define the information that the process has to deal with

● define what is critical vs. what would be nice for the first version of the system

● bring up any problems that exist in the current process or any opportunities for making it more efficient

● research policy questions when a new business procedure is being proposed

● analyze if there are any obstacles to success in the current environment of their office for implementing the new system

● create test cases for testing ● run test scripts on the cases ● give the developers feedback on the usability and

accuracy and effectiveness of the system in an organized, documented way

● help prepare documentation on how the system works from a client's point of view

● help prepare and implement training for other clients

All Team Members - have the following responsibilities:

● Commitment to the team● Regular attendance● Actively listen● Actively participate ● Identify concerns ● Brainstorm ideas ● Recommend solutions● Agree upon a design by consensus● Assist with project duties

Interviewing JAD & Questionnaire

ISYS-1117

JAD Specification & SRS

hecklist for getting a JAD started:

Table Of Contents


1. Define the Project The JAD Project Leader meets with the Project Sponsor to complete a JAD Project Charter.

2. Form the JAD Group The Project Leader and Project Sponsor form the JAD Group making sure you have all affected areas represented. You will need a Project Sponsor, Project Leader, Business Users and Systems Analysts. A JAD Group should have 8 or fewer total members. It is hard to be effective with more than 15 members.

3. First JAD Meeting - Kick off MeetingYour first JAD meeting may have the following agenda items:

❍ Share problem definition and overall goal. Get consensus on these two items.

❍ Train each member of the new group on what a JAD Group is so they will understand the purpose, the roles and how a JAD works.

❍ Establish JAD Group expectations/responsibilities.❍ Determine meeting frequency, time and place. ❍ Determine roles - Project Sponsor, Project Leader, Recordkeeper,

Timekeeper, Clients. ❍ Continue holding JAD meetings approximately every week or every other

week until you have reached consensus on a design.

4. JAD Meetings - Planning, Analysis, Design Phase ❍ Review the current process - map it out ❍ Identify Problems/Challenges in the current process ❍ Brainstorm solutions for those problems and challenges ❍ Benchmark other organizations for possible solutions ❍ Consider Buy vs. Build ❍ Survey your customers for problems and ideas ❍ Evaluate list of generated ideas ❍ Determine your course of action - tasks to be accomplished ❍ Develop your timebox - list of tasks, who is assigned and when each task is

due. ❍ Present the Project Design to the Project Sponsor and Representative

Customers and Get the Thumbs Up❍ Communicate, Communicate, Communicate

5. JAD Meetings - Development, Execute, Finish Phase Meet every 2 weeks to make sure the development stays on track Agenda - how did we do on our goals?

❍ Discuss problems and challenges ❍ Make decisions jointly ❍ Set goals for next meeting ❍ Assign tasks

Assign as many of the project duties as possible to members of the JAD - this helps build buy in and a feeling of ownership towards the project.

How do you know if your JAD is successful?

Questions to ask● Are your meetings well attended? ● Are all affected parties involved/aware of decisions being made? ● Did you solve the true underlying problem? ● Is your solution accepted and used by your clients? ● Is the solution available on time?

Success Factors● A clear purpose shared by all team members - the project charter ● A diverse team, representative of all areas effected by this project. ● Every person in the group has equal responsibility and decision

making power.● Every idea is valuable. Throughout the JAD, listen and acknowledge

each idea and concern. Evaluating ideas during a brainstorming

session will shut down the creative process. The best idea may never get said out of fear of being shot down.

● Participation by everyone is very important. Encourage quieter members to speak, they often have the best ideas. Don't allow 1 or 2 members to dominate. This is the facilitators responsibility as well as the whole teams' responsibility.

● Listen when others speak, don't interrupt or talk while others are talking (side conversations may have great ideas...we don't want to miss them).

● Maintain a parking lot to record important issues that are not within the scope of this project.

● Don't hold meetings just to hold meetings. Only meet when there is something substantial to talk about.

● Don't let more than 3 or 4 weeks pass between meetings, you will loose momentum. Remember, each meeting is a motivation for the team to complete tasks assigned. It is no fun to come to a meeting and admit you didn't finish your task.

● Decisions are reached by consensus. We are here to create a win/win solution...win/lose solutions aren't good enough. You can reach consensus by giving everyone three options:

❍ Thumbs up - I agree❍ Thumbs down - I disagree❍ Thumbs sideways - I can support this idea

Pitfalls: ● Sponsor not really committed - no resources ● Unclear goals or objectives - lack of direction ● Too many or too few members ● Not enough communication with outsiders affected by decisions● Timelines aren't kept● Project Creep - project grows beyond the original definition and scope

❍ if this really needs to happen, it is time to rewrite the project charter● Meetings aren't well facilitated

❍ don't have an agenda ❍ don't stick to agenda ❍ don't begin or end on time ❍ feels like nothing is accomplished in the meeting - old items not within

scope keep getting revisited over and over ❍ 1 or 2 members dominate discussions

JAD Group Benefits● Communication, Communication, Communication

● Build consensus and ownership ● Improve design quality - combined knowledge = better solutions ● Design cross-functional solutions● Helps project teams get focused and stay focused● Helps you get the right job done at the right time

QuestionnairesQuestionnaires are often used when there is a large group of people from whom the information is needed. Normally a questionnaire is for the outside use of the organization. The reach and scope covered can be much wider as compared to other methods of fact finding. The steps involved with this mode of fact-finding are:

● Seleceting th right participants, ● Desiging the questionnaire, ● Administering the questionnaire and ● Folllowing-up.

Designing the questionnaire is pretty much the same as designing an Interview-the only difference is that while designing the questionnaire, it is important to keep in mind that the questions should:

● not be vague ● self-explanatory ● a proper mix of open, closed and probe category ● be consistent in style ● be as such that related questions are grouped together, so that it is easier for the

respondent. ● begin with on some interesting note so that it motivates the respondent to answer

the whole questionnaire ● not be very lengthy ● provide anonymity to the user.

Just like a JAD or an interview session, a follow-up is important in order to gain from this technique. Have a look at a simple yet effective questionnaire - http://you-too.agderforskning.no/questionnaire.htm

Checkpoints1. What is Document Analysis?

http://you-too.agderforskning.no/questionnaire.htm

http://you-too.agderforskning.no/questionnaire.htm

ISYS-1117

JAD & Questionnaire SRS

A specification that will not fit on one page of 8.5x11 inch paper cannot be understood. --Mark Ardis

efore we go ahead we have to understand the following two terms:

● Specifications ● SRS

Table Of Contents


Specification

A specification is a representation of a requirement in a manner that will enable a developer to successfully implement it in software. It describes WHAT is to be implemented in terms that are unambiguous, complete and testable. The representation may be:

❍ natural language ❍ graphical or diagrammatic ❍ executable specification (prototype) ❍ mathematical representation

Of course one can write good specifications or bad ones. Since specifications are used as reference points during the product/concept implementation, it is important that specifications are:

❍ Clear and Concise ❍ Unambigious and ❍ Understandable

Consider an example of a very nicely written clear cut specification.

Consider a common example of a word processor providing a select command,specified in the following way- Selecting is the process for designating areas of your document that you wnat to work on. Most editing and formatting actions require two steps: first you select what you want to work on, such as text or graphics; then you initiate an appropriate action.

SRS(Software Requirements Specification) A Software Requirements Specification(SRS), or Requirements Analysis Document, is produced at the end of the Requirements Elicitation and Analysis Stage. This document is a major milestone in the software development process.

Checkpoint● Give a specification for the justify function in MICROSOFT WORD

No answer for this - try on your own

JAD & Questionnaire SRS



All Rights Reserved



ISYS-1117

Specification & SRS Functional vs Non-functional requirements

he National Bureau of Standards, IEEE(Standard No. 830-1984) and

the U.S. Department of Defense have proposed a standard format of an SRS document. A simplified version of this is as follows:

Table Of Contents


I. Introduction A.System reference B.Overall description C.Software project constraintsII. Information Description A. Information content representation B. Information flow representationIII.Functional DescriptionIV. Behavioural DescriptionV. Validation and Criteria A.Performance bounds B.Classes of tests C.Expected software response D.Special ConsiderationsVI. BibliographyVII.Appendix

The Introduction states the goals and objectives of the software.The Information Description provides a detailed description of the problem that the software must solve.

The Functional Description provides a narrative for each of the functions required to solve the problem.The Behavioural Description examines the operation of software as a result of external events and internally generated characteristics.The Validation and Criteria is the most important and it describes the result of all the tests and other considerations.

IEEE also states that a good SRS must be :

● Unambiguous ● Complete ● Consistent ● Modifiable ● Verifiable ● Traceable ● Usable during the Operation and Maintenance phase

How can I write a GOOD SRS?Always remember the following apsects and you would always end up with a very good SRS:

● SRS must say certain things. For example, software developed from an SRS that fails to specify that error messages will be provided, will probably fail to satisfy the customer.

● It must say those things in a certain way. For example, software developed from an SRS that fails to specify the format and content of error messages and instead is developed from a vague and non-quantifiable requirement such as All error messages will be helpful will probably be unsatisfactory as what is helpful for one person can be a severe aggravation to another person.

● SRS should NOT describe any design, verification, or project management details, EXCEPT for required design constraints.

Checkpoint1. What are some constraints that you can mention in a SRS document? 2. Outline some major difficulties that are encountered during analysis process? 3. What is the importance of having an SRS?

Specification & SRS Functional vs Non-functional requirements

ISYS-1117

SRS Specification review

"Success is more a function of consistent common sense than it is of genius. --An Wang

lease understand that Functional requirements capture the intended

behavior of the system. This behavior may be expressed as services, tasks or functions the system is required to perform. In product development, it is useful to distinguish between the baseline functionality necessary for any system to compete in that product domain, and features that differentiate the system from competitors products, and from variants in your company’s own product line/family.

Table Of Contents


Features may be additional functionality, or differ from the basic functionality along some quality attribute (such as performance or memory utilization). One strategy for quickly penetrating a market is to produce the core, or stripped down, basic product, adding features to variants of the product to be released shortly thereafter. This release strategy is obviously also beneficial in information systems development, staging core functionality for early releases and adding features over the course of several subsequent releases. In many industries, companies produce product lines with different cost/feature variations per product in the line, and product families that include a number of product lines targeted at somewhat different markets or usage situations. What makes these product lines part of a family, are some common elements of functionality and identity. A platform-based development approach leverages this commonality, utilizing a set of reusable assets across the family. These strategies have important implications for software architecture. In particular, it is not just the functional requirements of the first product or release that must be supported by the architecture. The functional requirements of early (nearly concurrent) releases need to be explicitly taken into account. Later releases are accommodated through architectural qualities such as extensibility, flexibility, etc. The latter are expressed as non-functional requirements. Use cases have quickly become a widespread practice for capturing functional requirements. This is especially true in the object-oriented community where they originated, but their applicability is not limited to object-oriented systems.

However, Non-Functional Requirements (NFRs) of a system are attributes and characteristics of the system.Think of functional requirements as verbs, and NFRs or attributes as adjectives or adverbs. Two products could have exactly the same functions, but their attributes can make them entirely different products. A Rolls Royce has more or less the same functions as a Yugo, but many, many different attributes.

Some examples of a non-functional requirement can be:

● Performance - throughput features of sytem such as response time ● Useability features - easy to learn and use ● Efficiency - minimal use of computing resources ● Reliability features - eg. long mean-time between failures; availability, correctness ● Security features - eg. prevents unauthorized access to programs and data ● Robustness - works in the presence of invalid input, faults, stressful conditions ● Adaptability - reusable in other environments, for other problems ● Scalability - works with large data sets ● Portability - easily modified to work on different platforms ● Modifiability - easily extended with new features

As per L. Chung, B. A. Nixon, E. Yu and J. Mylopoulos Non-Functional Requirements in Software Engineering presents a systematic and pragmatic approach to `building quality into' software systems. Systems must exhibit software quality attributes, such as accuracy, performance, security and modifiability-as mentioned above. However, such non-functional requirements (NFRs) are difficult to address in many projects, even though there are many techniques to meet functional requirements in order to provide desired functionality. This is particularly true since the NFRs for each system typically interact with each other, have a broad impact on the system and may be subjective. To enable developers to systematically deal with a system's diverse NFRs, this book presents the NFR Framework. Structured graphical facilities are offered for stating NFRs and managing them by refining and inter-relating NFRs, justifying decisions, and determining their impact. Since NFRs might not be absolutely achieved, they may simply be satisfied sufficiently. To reflect this, NFRs are represented as `softgoals', whose interdependencies such as tradeoffs and synergy, are captured in graphs. The impact of decisions is qualitatively propagated through the graph to determine how well a chosen target system satisfies its NFRs. Throughout development, developers direct the process, using their expertise while being aided by catalogues of knowledge about NFRs, development techniques and tradeoffs, which can all be explored, reused and customized. Non-Functional Requirements in Software Engineering demonstrate the applicability of the NFR Framework to a variety of NFRs, domains, system characteristics and application areas.

ISYS-1117

Functional vs Non-functional requirements References & Acknowledgment

Reviewing has one advantage over suicide: in suicide you take it out on yourself; in reviewing you take it out on other people. George Bernard Shaw (1856 - 1950)

he final stage of our specification process is the Specification Review

Stage. Review is conducted by both software developer and customer. Extreme care should be taken in this step as it forms the foundation for design and subsequent activities. Review is conducted at macroscopic levels and the following aspects are covered:

Table Of Contents


● Do the functions meet the scope? ● Are the constraints recognised?

● Can the system be partitioned effectively? ● Can the system be developed in stages? ● Are diagrams clear? ● Do inconsistencies, ommission or redundancy exist? ● Is the customer contact complete? ● How are planning estimates affected?

In order to develop answers to many of the above questions, it might be necessary to go to a detailed level, each individual specification analysed for hidden meanings, ambiguities and problems. In that case one might look for

● Missing requirements ● Consistency among requirements ● Requirements that are ambiguous ● Requirements that are not correct ● The value of each requirement to the customer ● Factors that will increase project risk ● Look for statements that imply certainty (eg always,every,all,none,etc.), then ask

for proof

Once the review has been completed, the software is “signed off” by both client and developer. The SRS becomes the “contract” for software development. Changes in requirements requested after the specification is finalised are not eliminated, but the client knows that each after-the-fact change is an extension of software scope and therefore can increase cost and/or protract the schedule.

Functional vs Non-functional requirements References & Acknowledgement



All Rights Reserved



ISYS-1117

Table Of Contents


The following books were useful during the preparation of this material:

● Systems Analysis and Design -- Dennis Wixom ● Software and its development-Joseph M.Fox -- Prentice Hall ● Software State-of-Art :Selected Papers -- Dorset House Publishing ● Fundamentals of Software Engineering -- Carlo Ghezzi,Mehdi jazayeri and Dino

Mandrioli--Prentice Hall ● CASE-IEEE-2nd Ed ● Sofware Engineering -- by Roger S. Pressman -McGraw Hill International Editions

Following websites were refereed to :

● ISYS1117 Subject Home Page ● http://www.utdallas.edu/~chung/BOOK/book.html ● http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF ● The icons have been picked up from this website

Written by Shekhar Kalra.Reviewed by Laura Thomson & Clemens Mayr.

https://inside.cs.rmit.edu.au/~laura/se/

http://www.utdallas.edu/~chung/BOOK/book.html

http://www.bredemeyer.com/pdf_files/NonFunctReq.PDF

http://www.coolarchive.com/icons.cfm

chapter3 requirement analysis.pdf

Documents

new system

requirements specification

current system

system developer

requirements analysis

users requirements

nontrivial system

software implementation