Overview

• Use research and information literacy skills to do independent research of business or organization

• Draft description of business (overview, environment, mission, goals, objectives, model, information environment, structure)

• Start list of definitions (any words or phrases that have special meaning beyond normal dictionary definitions), acronyms and abbreviations

• Start list of references

• Start list of stakeholders

Details

This assignment should take about 4-6 hours.

Read (seriously, and take notes)

1. SWEBOKwiki Business or Mission Analysis

2. 29148-2018 6.2 Business or mission analysis process

3. The Business Analysis Process: 8 Steps to Being an Effective Business Analyst (through step 4)

4. Research / Information Literacy

5. "Software Requirements" Weigers book Ch. 4 The business analyst

6. "Software Requirements" Weigers book Ch. 5 Establishing the business requirements

The purpose of the Business or Mission Analysis process is to define the business or mission problem or opportunity, characterize the solution space, and determine potential solution class(es) that could address a problem or take advantage of an opportunity.

29148-2018 6.2

Prepare

Add a page in your OneNote named Business Analysis Notes

• Create a heading 1 named In General

  • Create a heading 2 named Research

    • Create a heading 3 for the title of each reading and add links to pages you read along with notes from readings.

• Create a heading 1 named In My Project

  • Create a heading 2 named Research

    • Create a heading 3 for each source you use to gather information about the business and what you learned.

Tasks

• Review identified problems and opportunities in the organization strategy with respect to desired organization goals or objectives.

• Define the business or mission analysis strategy.

• Identify and plan for the necessary enabling systems or services needed to support business or mission analysis.

• Obtain or acquire access to the enabling systems or services to be used.

This is the first of the Activity assignments, based on the activities listed in 29148-2018. Read more about the activities and tasks in 29148 and the other standards cited in it. The best way to learn is by doing, so these assignments are designed to get you actively participating in the requirements engineering process. You should start with a sponsor in mind, like a business or organization, not a project. A sponsor could be a department on campus, a student club or organization, a non-profit, a family business, or a corporation. To get the most out of this class you will need find a sponsor that is willing to work with you. If you cannot find one, let the professor know. You are not expected to actually create a program for this class. In this class you will do all the things that need to be done before actually designing and building a program. Make sure the sponsor is aware of this. You could choose to create software for the sponsor separate of this course as an internship, for service hours, for pay, or just to build your portfolio if you have the time and the interest. There is a possibility that you could continue to work with the sponsor you find now during your senior year when you will need to actually create software for a class.

To create software that fills the needs of a client, you need to know their business. Sometimes, a person with a different role, like a business analyst, will do the majority of this work for a software engineer and just hand over a document like a Business Requirements Specification or Concept of Operations that tells you everything you need to know. Sometimes, like in this case, the software engineer needs to also do the work of a business analyst. Incidentally, if you decide that you don't really like software engineering, you could still complete the degree program but instead get a job as a business analyst. The skills are pretty transferable.

Once you find a sponsor willing to work with you, first, do as much independent research about the business as you can. When you meet with them you want to impress them with your prior knowledge and not waste their time having to explain things to you that might be on their web site for example. Look below to see what kind of information you are expected to gather.

Next, have your first formal meeting with the sponsor to learn more about the business or organization. Confirm and clarify what you have learned through your independent research. Fill in any blanks and add to what you already have for the information you are expected to gather.

You should not have to create any of this information, your sponsor should be able to provide it or you should be able to discover it through research. It does not have to be totally complete. I know you are not an experienced business analyst. It should, however, reflect time, effort, research ability, critical thinking, and writing ability.

Although they will vary depending on the size and type of the business, the type of questions you need to answer include:

• What are the main objectives of the business?

• What results are you hoping to be obtained through or by new software? (MOST IMPORTANT) (keep it general and high level)

  • How could it be proven that those results were obtained?

  • By when do these results need to be obtained?

• What is the business model / How is the business mission achieved (how is money made / service provided)?

• Where is key business information stored? How is it stored and accessed? Who is responsible for the information?

• What are the major internal divisions of the business?

• What are the external entities associated with the business?

• How are the internal divisions and external entities interrelated?

  • Is there a diagram describing the interrelation?

• What words have a special meaning within the business?

• What acronyms and abbreviations are used within the business?

• Who are the individuals or organizations that would have an interest in any software that might be developed? (users, customers, market analysts, regulators, software engineers, etc.)

  • How will they influence the organization and business? (Who has decision-making authority?)

  • How will they be related to the development and operation of the system? (Is there a team of developers already? Is there someone to train users? Is there someone to support a new system?)

• Do you have an organization chart?

• What laws and regulations govern the business?

  • Is there a regulations handbook or something similar?

• What are the social responsibilities of the business?

• What is the technology base of the business (exisiting hardware and software, technical proficiency of employees, etc.)? (For example, it would be good to know if everyone uses an iPhone or if they already use AWS.)

Create a document in Word or Google Docs named Business Specification

Make a heading 1 for Introduction

• This is just a heading and doesn't need to contain any content.

Make a heading 2 for each of the following and fill in as much as you can at this time based on your research. You will continue to add to this as you learn more about the business.

• Business Overview - Describe major internal divisions and external entities of the business domain concerned and how they are interrelated. A diagrammatic description is recommended.

• Definitions - Provide definitions for any words or phrases that have special meaning beyond normal dictionary definitions.

• Major stakeholders - List the stakeholders or the classes of stakeholders and describe how they will influence the organization and business, or will be related to the development and operation of the system.

Make a heading 1 for References

• Add a complete list of all documents referenced elsewhere;

• Identify each document by title, report number (if applicable), date and publishing organization

Make a heading 1 for Business management

Make a heading 2 for each of the following and fill in as much as you can at this time based on your research and sponsor meeting. You will continue to add to this as you learn more about the business.

• Business environment - influences to the business and consequently the system from external conditions like market trends, laws and regulations, social responsibilities and technology base

• Mission, goals, and objectives - IMPORTANT, describe the business results to be obtained through or by the proposed system.

• Business model - Describe methods by which the business mission is expected to be achieved. The description should be concentrated on the methods supported by the system to be developed or changed with the items such as product and services, geographies and locales, distribution channels, business alliance and partnership, and finance and revenue model.

• Information environment - Where is key business information stored? How is it stored and accessed? Who is responsible for the information?

Create a heading 1 for Appendix

• Create a heading 2 for Acronyms and abbreviations

This assignment will not be graded very critically. It is mostly to motivate you to get started and give you an opportunity to get feedback before turning in the much more important BRS assignment, which will include this content.

Submit two documents, your Business Analysis Notes and your Business Specification.

Overview

• Meet with sponsor

• Revise description of business (overview, environment, mission, goals, objectives, model, information environment, structure)

• Apply critical thinking (5 Why's)

• Draft purpose of solution

• Draft scope of solution - name, what it does (operational concept), objectives

• Start list of assumptions

Details

Read

1. SWEBOK Ch. 1 section 1.1

2. SWEBOK Ch. 13 section 1

3. 29148-2018 6.2.3.3 Define the problem or opportunity space

4. Problem Solving from the course web site (also watch videos)

Tasks

• Analyze the problems and opportunities in the context of relevant trade-space factors.

• Analyze customer complaints, problems and opportunities in the context of relevant trade-space factors.

• Define the mission, business, or operational problem or opportunity.

Once you have learned about a business, you should be able to identify problems or opportunities for improvement. Sometimes stakeholders will be able to simply tell you the problem. Other times, they might describe a problem but not the real problem. The 5 Why's is a useful strategy in this situation. The goal for this activity is to define a problem that could be solved by software.

Working with your sponsor, identify the opportunity for developing a new solution, or improving a system-of-interest (SoI).

This must begin prior to starting the activities necessary to define stakeholder needs and requirements.

Add to your existing Business Analysis Notes the questions you ask, the answers you are given, and the results of any additional research.

Although they will vary depending on the size and type of the business, the type of questions you need to answer include:

• What is the problem you are trying to solve?

• Why do you want the new software? (for this class, the solution must involve the development of software)

• How will the proposed system contribute to meeting business objectives?

• What is the range of business activities performed?

• What is the scope of the system being developed or changed? (what it needs to do vs what doesn't it need to do)

• What are the main business activities?

• How and in which context does the system supports the business activities?

• What are the business operational policies and rules?

• What conditions are to be imposed in conducting the business process?

• What is the organizational structure (divisions and departments)?

• What are the role and responsibility structures?

Add to your existing Business Specification page

Above the Business Overview, add a heading 2 for Business Purpose

• Describe why the organization wants the new software.

• Describe how the proposed system will contribute to meeting business objectives.

• This section could be important to get the go-ahead from decision makers to develop the software.

• Do not describe a solution.

Under Business Purpose, add a heading 2 for Business Scope

• Identifying the business (or division) by name;

• Define the range of business activities they perform.

• Describe the scope of the system being developed or changed.

• Do not describe a solution.

Under the Information Environment, add a heading 1 for Business Operations

• Add a heading 2 for Business processes - Provide description of the procedures of business activities and possible system interfaces within the processes. The purpose of this information item is to represent how and in which context the system supports the business activities.

• Add a heading 2 for Business operational policies and rules - Describe logical propositions applied in conducting the business processes. The propositions may be conditions to start, branch and terminate the sequence of the business activities in the business processes; criteria for judgment in the business processes; or formula to evaluate a quantity, which will likely be addressed in functional requirements in the SyRS and SRS. The policies and rules shall be uniquely named and numbered, and shall be referenced in the description of the business processes.

• Add a heading 2 for Business operational constraints - Describe conditions to be imposed in conducting the business process. The conditions may be on a performance constraint (e.g., the process shall be finished within a day after the triggering event occurs), or may be from a management requisite such as 'every occurrence of the process shall be monitored and recorded'.

• Add a heading 2 for Business operational modes - Describe methods to conduct the business operation in an unsteady state, for example, a state when business operations might be extremely busy due to some intensive occurrence of events. An unsteady state of business operation includes a manual operation mode when the proposed system is not available due to some unexpected situation like an accident or natural disaster.

• Add a heading 2 for Business operational quality - Define the level of quality required for the business operation. For example, a business process may address required urgency with higher priority than the reliability of the business process.

• Add a heading 2 for Business structure - Identify and describe the structures in the business relevant to the system, such as organizational structure (divisions and departments), role and responsibility structures, geographic structures and resource sharing structures.

Under Acronymns and Abbreviations, add a heading 2 for Assumptions

• An assumption is "a thing that is accepted as true or as certain to happen, without proof."

• Recognizing assumptions is a key skill of critical thinking.

• Make a bulleted list of some assumptions (at least 6) that you and / or the clients are making related to the business and the problem.

Submit your Business Specification

Overview

• Draft business operational requirements

• Start list of resources / limitations / constraints such as money, time, personnel, and materials

• Revise list of stakeholders

• Define preliminary operational concept

Details

Read

• 29148-2018 6.2.3.4 Characterize the solution space

• 29148-2018 6.2.3.5 Evaluate alternative solution classes

• 29148-2018 9.3.16 High-level operational concept

• 29148-2018 9.3.17 High-level operational scenarios

• 29148-2018 9.3.18 Other high-level life-cycle concepts

• 29148-2018 9.3.19 Project constraints

• MITRE Systems Engineering Guide - Concept Development pps 275-300

• "Software Requirements" Weigers book Ch. 5 Establishing the business
  requirements

• System Definition Document / BRS page on the course web site

Tasks

• Define preliminary operational concepts and other concepts in life cycle stages.

• Identify candidate alternative solution classes that span the potential solution space.

• Assess each alternative solution class.

• Select the preferred alternative solution class(es).

Research and meet with your sponsor again to learn more specifics about the business / organization and start to think about the solution broadly. "The eventual system solution can be a new system, an evolution of an existing system or set of systems, an operational change to an existing system or set of systems, or some combination of these." 29148-2018 6.2.3.4

Add to your existing Business Analysis Notes the questions you ask, the answers you are given, and the results of any additional research.

Although they will vary depending on the size and type of the business, the type of questions you need to answer include:

• What policies will need to be followed?

• What resources are available in developing a solution (people, hardware, software, money, etc.)?

• What limitations or constraints exist related to developing a solution (hardware, software, money, time, personnel, materials)?

• Ask again: Who are the individuals or organizations that would have an interest in the solution? (users, customers, market analysts, regulators, software engineers, etc.)

  • How will they influence the organization and business? (Who has decision-making authority?)

  • How will they be related to the development and operation of the system? (Is there a team of developers already? Is there someone to train users? Is there someone to support a new system?)

• Work together to develop a description of the proposed system.

• Does there need to be different modes of system operation?

• What resources are available related to supporting the proposed system? (FAQ, help desk, etc.)

• How will users/operators/maintainers interact with the system?

• Which stakeholders should be engaged with?

• Contracting issues (at least hypothetically)

  • Cost

  • Schedule

• What design elements are important for the solution?

• Is there a specific method of production that needs to be followed (certain methodology, software, languages, etc.)?

• Who will do the verification that the solution meets requirements and is there a specific process you would like followed?

• What will it look like when people start using the solution?

• What support is available for when the solution is in use? (operating support, engineering support, maintenance support, supply support and training support)

• Are there any requirements related to retiring the solution at the end of its life? Are there record retention policies?

• What are the constraints to performing the project within cost and schedule?

Revise your Business Specification page.

Under the Business Structure section...

Add a heading 1 for Preliminary operational concept of proposed system

• Add a heading 2 for Preliminary operational concept - Describe the proposed system in a high-level manner, indicating the operational features that are to be provided without specifying design details. As much as possible, include operational policies and constraints, modes of system operation, user classes and other involved personnel, and the support environment.

• Add a heading 2 for Preliminary operational scenarios - Describe examples of how users/operators/maintainers will interact with the system in important contexts of use. The high-level scenarios are described for an activity or a series of activities of business processes supported by the system. The scenarios should be uniquely named and numbered.

Add a heading 1 for Preliminary life-cycle concepts

• Add a heading 2 for Preliminary acquisition concept - describes the way the system solution will be acquired including aspects such as stakeholder engagement, source of the solution, requirements definition, solicitation and contracting issues, design, production and verification.

• Add a heading 2 for Preliminary deployment concept - describes the way the system solution will be validated, delivered and introduced into operations.

• Add a heading 2 for Preliminary support concept - describes the desired support infrastructure and manpower considerations for supporting the system solution after it is deployed. A support concept addresses operating support, engineering support, maintenance support, supply support and training support.

• Add a heading 2 for Preliminary retirement concept - describes the way the system will be removed from operation and retired, including the disposal of any hazardous materials used in or resulting from the process.

Add a heading 1 for Project Constraints

• Describe constraints to performing the project within cost and schedule. (IMPORTANT)

Submit your Business Specification page.

Overview

• Set up Jira

  • Start Tool Presentation

• Add goals / objectives

• Add operational policies and business rules

• Describe and create BRS / ConOps / System Definition Document

• Complete Business Analysis Report

Details

Read

1. 29148-2018 6.2.3.6

2. OKRs: goal setting that focuses on outcomes

3. Business Rules: An Agile Introduction

4. Jira page on course web site

Tasks

• Maintain traceability of business or mission analysis.

• Provide key [artifacts and] information items that have been selected for baselines.

Task 1

Related to the task of maintaining traceability:

"Requirements traceability should be established and maintained to document how the business needs and requirements are intended to meet the business problems and opportunities and how they are related to preferred alternative solution classes and stakeholder needs and requirements. Business and mission needs and requirements need to be captured, traced, and maintained throughout the system life cycle and beyond. Use of a requirements management tool can facilitate this process."

The requirements management tool we are going to use in this class is Jira. Jira is an extremely popular tool so learning it will help you in the future.

Create a page in your OneNote for Jira Notes. Document what you do in Jira and take notes about what Jira can do.

Sign up for the Free Plan for Jira and the Free Plan for Confluence. Do not do the Free Trial of the Standard Plan.

In Jira, click Create project and create a team-managed project. The project name can be your solution name (if you have one) or just the business or organization name. Choose a descriptive and easy to type project key. Use the Kanban template. Turn on the following features: Roadmap, Backlog, Sprints, Pages.

You will use Pages for all "real" project related artifacts that you would share with a client / sponsor.

Copy and paste your Business Specification into Confluence.

You will use the Blog for all meta / course related artifacts that you will share with the instructor and will serve as a resource for you when you have to do these activities in the future, like your notes. You could also take the mindset that you could share your Blog with potential employers to demonstrate your methodology and skillset or that your blog is to help teach other people.

Add the following new issue types in Jira:

• Objective

• Constraint

This can be done from Project Settings, Issue types, + Add issue type, Create issue type. https://confluence.atlassian.com/adminjiracloud/adding-editing-and-deleting-an-issue-type-844500747.html

• Choose the grey and white O icon for the Objective issue type.

• Choose the lock icon for the Constraint issue type.

• These are not standards, they are just to make grading easier.

Dissect your Business Specification document and notes you took when researching and meeting with your sponsor to add objectives and constraints to Jira.

When you add them, type a brief sentence for each issue in the Backlog page where it says "What needs to be done?". This is the Summary field of the issue.

Optionally, click on the issue to bring up its fields. From here you can add a longer description, identify the source, add an attachment, add links, and more.

Replace the content in the Mission, goals, and objectives section in your Business Specification with a Jira table.

• Use /jira to add a table

• Use type = objective to filter issues.

• Delete the number in the Maximum issues box to get all issues.

• In Display options, choose to show Key, Summary, and Description in that order

Replace the content in the Constraints section in your Business Specification with a Jira table.

• Use /jira to add a table

• Use type = constraint to filter issues.

• Delete the number in the Maximum issues box to get all issues.

• In Display options, choose to show Key, Summary, and Description in that order

Task 2

Related to the task of providing key information items:

At this point, you have completed the Business or mission analysis process (29148 6.2). For projects you work on in the future, a business analyst may do this process and just give you a BRS or something like it.

• Complete your BRS assignment. (IMPORTANT)

• Create a Blog post in Confluence named Specification Notes.

  • Create a heading 1 named Introduction using the dropdown box at the top left

    • You can leave this section empty for now.

  • Create a heading 1 named Business Requirements Specification (BRS) General Description

    • Create a heading 2 for each of the following and provide the corresponding information (REQ.rsd.1):

      • General description - identify other names this type of document could be called

      • Audience

      • Structure

      • Attributes

      • Standards

• • Create a heading 1 named My Business Specification Review

    • Describe what you did to create your BRS.

    • Clearly describe your proficiency in writing skills and how you used techniques from the Writing page on the course web site.

Important: While logged in to Atlassian, go to https://admin.atlassian.com/ and invite profvanselow@gmail.com as a team member so I can access your site for grading. You should only need to do this once but might need to do it for Jira and Confluence.

Customize the Overview page by clicking on it at the top left within Confluence and following the provided instructions. Delete the provided welcome text box. Read the linked pages. Make this a professional looking landing page for your project.

In your overview page, add

• a heading 1 for Information Items / Specifications

  1. a link to your BRS (your polished up Business Specification page)

• a heading 1 for Requirements Activity Notes

  1. a link to your Business Analysis Notes

  2. a link to your Specification Notes

• a heading 1 for Requirements Activity Reports

  1. a link to your Business Analysis Report (your polished up Business Analysis Notes)

• a heading 1 for Practical Considerations and Software Requirements Tools

  1. a link to your Jira Notes

Submit a link to your overview page.

• It will look like https://username.atlassian.net/wiki/spaces/projectkey/overview

Overview

• Add to list of stakeholders

  • Apply critical thinking (use Elder Paul Elements of Thought)

• Describe user characteristics

• Collect sources / research (goals, domain knowledge, stakeholders, business rules, operational environment, organizational environment)

• Plan elicitation techniques (interviews, scenarios, mockups, facilitated meetings, observation, user stories, other)

• Add to references

Details

Read

1. SWEBOK Ch. 1 section 2.2 Process Actors

2. SWEBOK Ch. 1 section 3.1 Requirements Sources

3. SWEBOK Ch. 11 section 2.4

4. 29148-2018 5.2.2

5. 29148-2018 6.3.3

6. 29148-2018 9.6.6

7. Stakeholder Needs and Requirements from SEBOKwiki

8. Wiegers Beatty Ch. 6 Finding the voice of the user

9. Stakeholder Analysis Mind Tools

10. SWEBOK Ch. 1 section 3.2

11. SWEBOK Ch. 15 section 5.3

12. 29148-2018 6.4.3.2

13. MITRE Requirements Engineering 301-303

14. MITRE Eliciting, Collecting, and Developing Requirements 304-313

15. the Elicitation page on the course web site

    • Interview Agenda Worksheet (doc) requirementsquest.com

    • Good Questions to Ask Your Client (PDF)

16. Constraint agilemodeling

A stakeholder is an "Individual or organization having a right, share, claim, or interest in a system or in its possession of characteristics that meet their needs and expectations" (ISO/IEC/IEEE 2015).

Tasks

• Identify the stakeholders who have an interest in the [software] system throughout its life cycle.

• Define the stakeholder needs and requirements definition strategy.

• Identify and plan for the necessary enabling systems or services needed to support stakeholder needs
  and requirements definition.

• Obtain or acquire access to the enabling systems or services to be used.

Create a Blog post named Elicitation Notes

• Create a heading 1 named Requirements Elicitation in General

  • Create a heading 2 named Elicitation Sources

    • Create a heading 3 for each of the bulleted sources from SWEBOK Ch. 1 section 3.1

    • Write a brief description in your own words for each.

    • In the Stakeholders section

      • Create a heading 4 named Examples of Stakeholders

        • List and and describe typical examples of software stakeholders. (SWEBOK 2.2)

      • Create a heading 4 named Identifying stakeholders

        • Describe how you can go about identifying stakeholders involved with software engineering projects in general.

  • Create a heading 2 named Elicitation Techniques

    • Create a heading 3 for each of the bulleted techniques from SWEBOK Ch. 1 section 3.2

    • Write a brief description in your own words for each.

    • In your User stories section be sure to include the template “As a <role>, I want <goal/desire> so that <benefit>.”

• Create a heading 1 named Requirements Elicitation in My Project

  • Create a heading 2 named Elicitation Sources

    • Create a heading 3 for each of the bulleted sources from SWEBOK Ch. 1 section 3.1

    • Describe what specifically you used as sources for each source category

    • In the Stakeholders section,

      • Create a heading 4 named Stakeholders

        • List and and describe the stakeholders for your project (you should be able to copy and paste from your BRS)

        • Add additional stakeholders discovered during elicitation.

      • Create a heading 4 named Identifying stakeholders

        • Describe how you went about identifying stakeholders involved with your software engineering project.

  • Create a heading 2 named Elicitation Techniques

    • Create a heading 3 for each of the bulleted techniques from SWEBOK Ch. 1 section 3.2

      • Write a description of how you have or how you plan to use each technique in detail. You do not necessarily need to use all of the techniques but it would be great if you did. Plan to elicit requirements related to functionality, performance, usability, interface, and database.

      • At a minimum, your plan should include:

        • Interviews of multiple stakeholders

          • List questions you will ask.

        • A mockup

          • Plan what you will use to make your mockup (Adobe XD recommended) and how you will use it to elicit requirements.

        • User stories

          • Plan how you will gather, form, and document user stories.

        • It may also be beneficial to conduct an observation.

Create a Page named Requirements Specification

• Create a heading 3 named User Characteristics

• • Make a bulleted list of the stakeholders or the classes of stakeholders and describe how they will influence the organization and business, or will be related to the development and operation of the system.

  • Acquire or create and include an Org. Chart if possible.

  • Describe general characteristics of the intended groups of users of your software including characteristics that may influence usability, such as educational level, experience, disabilities, and technical expertise.

• Create a heading 1 for References

  • Copy and paste your references from your BRS.

  • Add additional references used as elicitation sources.

Add a link to your Elicitation Notes and Requirements Specification to your Confluence overview page.

Submit a link to your overview page.

• It will look like https://username.atlassian.net/wiki/spaces/projectkey/overview

Overview

• Conduct elicitation using multiple sources / research (goals, mission profile, operational scenarios, operational environment and context of use, operational deployment, performance, effectiveness, operational life cycle, organizational environment, user and operator characteristics)

• Conduct elicitation using multiple techniques and involving multiple stakeholders (interviews, user stories)

• Make user stories

• Make wireframe

Details

Read

• 5 Essential Agile Techniques to Improve Your Requirements Documentation, especially about the INVEST principle

• User Story agilemodeling

• User stories atlassian

Reference

• SWEBOK Ch. 1 section 3.2

• SWEBOK Ch. 15 section 5.3

• 29148-2019 6.3.3.3

• Issues Tutorial atlassian

Tasks

• Define context of use within the concept of operations and the preliminary life cycle concepts.

• Identify stakeholder needs.

• Prioritize and down-select needs.

• Define the stakeholder needs and rationale.

Implement your plan to elicit requirements. Be sure to use a variety of sources. Elicit requirements related to functionality, performance, usability, interface, and database and identify design constraints.

Although this is just one assignment with one due date, this needs to be done many times in many different ways over a period of time. With Agile, requirements are continually elicted. "The requirements process is not a discrete front-end activity of the software life cycle, but rather a process initiated at the beginning of a project that continues to be refined throughout the life cycle." (SWEBOK Ch. 1 section 2.1)

Create User Stories

Edit your Elicitation Notes.

Add to the Elicitation Sources in the Requirements Elicitation in General section.

• Create a heading 3 for each source listed at the end of 29148 6.3.3.3.

• Write a brief description in your own words for each.

Add to the User stories section in the Requirements Elicitation in General section.

• Create a heading 4 for each reading from the top of the section and add notes from each reading.

Add to the User stories section in the Requirements Elicitation in My Project section.

• Create (or have users create and you collect and cleanup) user stories for your project using the template “As a <role>, I want <goal/desire> so that <benefit>.”

• Add the user stories in Jira then add a table of user stories in your notes.

  • Use /jira to add a table

  • Use type = story to filter issues.

  • Delete the number in the Maximum issues box to get all issues.

  • In Display options, choose to show Key, Summary, Description, and Issue Type, in that order

One time instructions to add the Issue type

• In Jira, add the Issue type Story in Project settings | Issue types | + Add issue type.

• Add the Priority field to the Issue type Story. (in Project settings | Issue types | Story) Help

• Jira will automatically create unique identifiers, which is important.

Instructions to add User Stories

• On the Backlog page, add one sentence user stories following the template above. This is the Summary field.

Add user stories as you continue to elicit requirements and develop your program.

With Agile, user stories can be pretty much the only "requirements".

Create a new heading 2 at the bottom of your Elicitatation Notes named Elicitation Summary.

• Include a detailed summary of what you did and how you did it and evidence of conducting elicitation, such as photos.

• Include your interview question answers.

In your Requirements Specification page, under References

• Create a heading 1 named Specific Requirements

  • Create a heading 2 named User Stories

    • Add a table of user stories from Jira as you did in your notes.

Submit a link to your overview page.

• It will look like https://username.atlassian.net/wiki/spaces/projectkey/overview

Overview

• Conduct elicitation using multiple sources and techniques and involving multiple stakeholders (observation, scenarios, mockup)

• Make mockup

• Plan acquisition, deployment, support, retirement

• Start use cases

• Write overview of product

Details

Read

• SWEBOK Ch. 1 section 3.2

• 29148-2018 6.3.3.4

• 29148-9.6.1 SRS overview

• 29148-9.6.2 Purpose

• 29148-9.6.3 Scope

• 29148-9.6.5

• "Software Requirements" Weigert book Ch. 15 Reducing risk through prototyping

• User Interface Design Basics

• Wiegers' Four Techniques for Defining Project Scope

• SWEBOK Ch.1 section 3.1 Requirements Sources

• 29148-2018 9.6.7 Limitations

• SWEBOK Ch. 1 section 4.2

• System Use Cases: An Agile Introduction

• "Software Requirements" Weigers book Chapter 8: Understanding user requirements

• the Use Case page on the course web site

Tasks

• Define a representative set of scenarios to identify all required capabilities that correspond to anticipated operational and other life cycle concepts.

• Identify the interaction between users and the system.

• Identify the factors affecting interactions between users and the system.

Task 1 Mockup

Perform more requirements elicitation using additional techniques.

Create a mockup for your proposed software. Keep this one simple as a tool for elicting requirements. You will make a more detailed prototype later.

• A wireframe is a rough sketch about how a website/app will look like. It is usually presented with gray lines, boxes, colors and placeholders. It is similar to the blueprint of a building.

• A mockup is a static wireframe with much more UI and visual details. A mockup is similar to a real-life building model.

• A prototype is dynamic (clickable) mockup.

Recommended software:

• Dedicated mockup software (learn something new to be able to add to the skills section of your portfolio)

  • Adobe XD, Figma, Sketch (Mac only), Balsamiq Mockups, or Mockplus

• IDEs / IDE integrations

  • Scene Builder, Android Studio, Visual Studio

Share the mockup with stakeholders as a means to refine exisiting requirements and elicit additional requirements. Submit evidence of sharing your mockup with stakeholders in the form of photos of them with the mockup or screenshots of electronic communication in which they provide feedback about the mockup.

In your Elicitatation Notes, in the Requirements Elicitation in My Project section, in the Elicitation Techniques section, in the Prototypes section

• Create a heading 4 named Mockup.

  • Describe the difference between a wireframe, mockup, and prototype.

  • Describe the process you took to make the mockup.

  • Summarize how you used it to elicit requirements.

  • Add your evidence of sharing your mockup with stakeholders.

  • Add a screenshot of your mockup.

  • A list of constraints on the system design imposed by external standards, regulatory requirements or project limitations.

    • Examples:

      • An Android app might need to follow Google's Material Design Guidlelines

      • Software may need to comply with WCAG 2.0 guidelines to make products acccessible.

Task 2 Use Cases

Start Use Cases for your project in your Requirements Specifications Supporting Information

In your Requirements Specification, under the heading 1 named Specific Requirements

• Add a heading 2 named Supporting Information

  • Add a heading 3 named Use Cases

You must have at least 4 use cases and 2 actors.

• Show “what” the software is supposed to do, not “how” this software will do it.

• Include:

  • use case names (brief and descriptive)

  • unique identifier

  • brief description

  • pre-conditions

  • post-conditions

  • basic flow / course of action (sunny day scenario)

  • alternate flows

• Optionally include:

  • actors (roles, not real people, with brief, descriptive names)

  • goals

  • triggers

  • exceptions

  • qualities

Task 3 Operational Concept

After a problem is defined and the solution has been broadly considered, you can get started on a more detailed solution. Develop a software based solution to the problem. Think critically and creatively.

In your Requirements Specification, at the top

• Create a heading 1 named Introduction

  • Create a heading 2 named Purpose

    • Copy and paste the purpose statement from the BRS, revising if necessary.

    • The purpose statement should answer the question "Why should this software be developed?", provide context on this project, and explain how it fits into the organization's strategic goals.

  • Create a heading 2 named Scope

  • Create a heading 2 named Product overview

    • Create a heading 3 named Product perspective

    • Create a heading 3 in your page named Product functions

      • Provide a summary of the major functions that the software will perform as a bulleted list, some of these will be based on the user stories. For example, an accounting program may address customer account maintenance, customer statement and invoice preparation without mentioning the vast amount of detail that each of those functions requires.

      • Insert use case diagram and use cases (created in another assignment)

    • Under User characteristics, create a heading 3 in your page named Limitations

      • Add Constraints as a Jira table.

        • Type /jira or click the + along the top menu bar and click Jira.

        • In the Search box type type = constraint

        • In Display options, choose to show Key, Summary, and Description in that order

      • Add more issues for any other items that will limit the programmers' options based on your elicitation.

      • 29148 provides some types of items that could result in limitations.
        a) regulatory requirements and policies;
        b) hardware limitations (e.g., signal timing requirements);
        c) interfaces to other applications;
        ...

      • Some sample limitations:

        • password length must be 8 characters

        • the system cannot go down for maintenance between 7 am and 7 pm on weekdays

        • the system must run on Android devices

        • the software must be written using Java

      • Plan to elicit more limitations as part of your requirements elicitation and then create more issues and update your page.

    • Create a heading 3 in your page named Definitions

      • Copy and paste the Definitions section from the BRS, adding to it as needed.

Submit a link to your overview page.

• It will look like https://username.atlassian.net/wiki/spaces/projectkey/overview

Overview

• Complete use cases

• As a result of application of elicitation techniques...

  • Specify requirements

  • Identify design constraints

  • Add to / revise definitions, acronyms, and abbreviations

  • Add to / revise operational policies and rules

  • Add to / revise references

  • Add to / revise user characteristics

  • Add to / revise list of stakeholders

  • Add to / revise constraints (money, time, personnel, and materials)

Details

Read

• 29148 6.3.3.5 Transform Stakeholder Needs into Stakeholder Requirements

• SWEBOK Ch. 1 section 3.2

• Requirements Construct section of course web site

• 29148-2018 5.2.6

• 29148-2018 5.2.7

• 29148-2018 5.2.8

Tasks

• Identify the constraints on a system solution.

• Identify the stakeholder requirements and functions that relate to critical quality characteristics such as assurance, safety, security, environment, or health.

• Define stakeholder requirements consistent with life cycle concepts, scenarios, interactions, constraints, and critical quality characteristics.

Complete use cases.

Use the results of your elicitation to write a complete set of requirements (at least 10, possibly many more) for your project.

Consider requirements related to functions, performance requirements, usability requirements, interface requirements, and logical database requirements. Consider the bullet points above.

In your Jira project, create a new Issue type named Requirement from Project settings | Issue types | Add issue type. Use the purple icon with the white lines (just to make grading easier, this is not a standard).

Add requirements in the Backlog. Type the requirement statement in the box that comes up after clicking the + in the Backlog. This is the Summary field. Each requirement should adhere to the Characteristics of individual requirements from 5.2.5.

For each requirement you add, click on it to bring up the properties / attributes. Review 29148-2018 5.2.8 Requirements attributes.

• At a minimum, include the following attributes:

  • Identification: done automatically by Jira

  • Version Number: done automatically by Jira in Activity - History

  • Stakeholder Priority: will be set in a later assignment

  • Rationale: write a description and / or link to a user story. Use the Description and / or a Label to identify the source of the requirement. Most functional requirements can be associated with a user story. For the sake of this assignment, link a user story to at least one requirement. To do this, click the chain icon next to the requirement. Each user story is likely to correspond to at least one, and possibly multiple requirements.

  • Type: in Jira, we are using the Issue Type Requirement, in a later assignment you will use the Labels field to identify the type of requirement.

• Optionally, if appropriate, set the following attributes:

  • Owner: in Issue Settings, add a People field named Owner

  • Risk

  • Difficulty

In your Requirements Specification, under the heading 1 named Specific Requirements

• Add a heading 2 named Formal requirement statements

• Add a Jira table of requirements

• Use type = requirement in the search box to filter issues.

• In Display options

  • Leave the Maximum issues box empty to get all issues

  • choose to show Key, Summary, Description, Linked Issues, Priority, and Labels, in that order (some of these will not be set yet)

Add to other sections as a result of further elicitation

• Add additional stakeholder related constraints

• Add additional definitions

• Add additional acronyms and abbreviations

• Add additional operational policies and rules

• Identify design constraints

• Add additional references

• Add additional stakeholders and user characteristics

Submit a link to your overview page.

Overview

• Classify requirements

  • Functional or Nonfunctional

  • Priority

• Make conceptual model (use case diagram)

• Perform requirements negotiation / "conflict resolution"

• Apply critical thinking (use Elder Paul Elements of Thought)

• Feed back the analyzed requirements to applicable stakeholders to validate that their needs and expectations were adequately captured and expressed (validation)

• Perform formal analysis using Characteristics of a set of requirements from 29148 (validation)

• Add to / revise purpose and overview of product

Details

Read

1. SWEBOK Ch. 1 section 4

2. SWEBOK Ch. 1 section 7.3

3. 29148-2018 6.3.3.6

4. "Software Requirements" Weigers book Chapter 16: First things first: Setting requirement priorities

5. The Analysis page on the course web site

Reference

1. SWEBOK Ch. 1 sections 1.2, 1.3, and 1.4

Tasks

• Analyze the complete set of stakeholder requirements.

• Define critical performance measures that enable the assessment of technical achievement.

• Feed back the analyzed requirements to applicable stakeholders to validate that their needs and expectations have been adequately captured and expressed.

• Resolve stakeholder requirements issues.

Task 1 Classify

In your Jira project, edit the Requirement Issue type to add the Priority field.

In the properties / attributes for each requirement...

• Set a Priority using the arrows (1-5). (see 5.2.8.2)

• Apply a label: functional or nonfunctional (see SWEBOK 1.3).

Requirements may also be classified based on...

• whether the requirement is derived from one or more high-level requirements or an emergent property, or is being imposed directly on the software by a stakeholder or some other source. (see SWEBOK 1.4)

• whether the requirement is on the product or the process (see SWEBOK 1.2)

• other attributes as described in 5.2.8.3

Task 2 Conceptual Model - Use Case Diagram

Create a Use Case Diagram for your project based on your use cases.

• Include:

  • Use cases. Each of your use case names that you created earlier drawn as a horizontal ellipse.

  • Actors. An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures. Consult your Stakeholder notes.

  • Associations. Associations between actors and use cases are indicated in use case diagrams by solid lines. An association exists whenever an actor is involved with an interaction described by a use case. Associations are modeled as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line. The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to indicate the primary actor within the use case but could be confused for data flow.

• Optionally include:

  • System boundary boxes. Draw a rectangle around the use cases, called the system boundary box, to indicates the scope of your system. Anything within the box represents functionality that is in scope and anything outside the box is not.

  • Packages. UML constructs that enable you to organize model elements (such as use cases) into groups.

Task 3 Requirements Negotiation

• Analyze your requirements to make sure there are not any conflicts.

• Consult with stakeholdres to reach a consensus on appropriate tradeoffs.

Task 4 Formal Analysis

• Compare your set of requirements to the Characteristics of a set of requirements from 29148 5.2.6. Create a table and check off that your set has the characteristics.

Feed back the analyzed requirements to applicable stakeholders to validate that their needs and expectations have been adequately captured.

Create a new page in Confluence named Analysis Notes

• Create a heading 1 for Requirements Analysis in General

  • Describe why requirements analysis is important (reference SWEBOK Ch. 1 section 4)

• Create a heading 2 for each of the numbered items in SWEBOK Ch. 1 section 4

  • Describe each in your own words

  • Within the Conceptual Modeling section, write a paragraph describing what a use case diagram is in general, with a list of its key components, and why it is beneficial.

• Add a heading 1 named Requirements Analysis in My Project

  • Describe how you applied critical thinking to analyze your requirements (use Elder Paul Elements of Thought)

  • Add a heading 2 named Requirements Classification

    • Under it, insert the requirements you just made using /jira. Tip: use type = requirement in the search box

    • Edit the table by clicking the pencil icon that appears below it when selected

      • Click Display options

      • Leave the Maximum issues box empty to get all issues

      • In Columns to display, click the X next to any column to remove it and click an empty area in the box to bring up other columns to add.

        • For this assignment, show Key, Summary, Description, Issue Type, Linked Issues, Priority, and Labels in that order.

        • If you set any optional attributes, (Owner, Risk, Difficulty) show them as well.

• • Add a heading 2 named Conceptual Modeling

    • Add a heading 3 named Use Case Diagram

      • Include your use cases, use case diagram and a paragraph describing the process you took to create your diagram including what software you used.

  • Add a heading 2 named Requirements Negotiation / "Conflict Resolution"

    • Write a paragraph describing how you fed back the analyzed requirements to applicable stakeholders to validate that their needs and expectations were adequately captured and expressed and resolved stakeholder requirements issues. Cite any specific requirements that conflicted and how they were resolved. If there weren't any conflicts, speculate on how requirements could have conflicted and how you would have resolved it.

  • Add a heading 2 named Formal Analysis

    • Include your table from 5.2.6.

In your Requirements Specification page, revise your purpose and overview of product as needed.

Add a link to your Analysis Notes in your overview page.

Submit a link to your Analysis Notes page.

Overview

• Make prototype (validation)

  • Based on results of elicitation with mockup and considering design constraints and user characteristics

• Describe StRS

• Add to Jira Notes

• Complete Elicitation Report

Details

Read

• 29148 6.3.3.7 Manage the stakeholder needs and requirements definition

• SWEBOK Ch. 1 section 6.2

• Sofware Requirements 3e - Wiegers and Beatty, Ch. 15: Risk reduction through prototyping

Tasks

• Obtain explicit agreement [with designated stakeholders] on the stakeholder requirements.

• Maintain traceability of stakeholder needs and requirements.

• Provide key [artifacts and] information items that have been selected for baselines.

• Make a prototype, based on results of elicitation with mockup, and considering design constraints and user characteristics, to be used for requirements validation.

Prototyping is commonly a means for validating the software engineer’s interpretation of the software requirements, as well as for eliciting new requirements. As with elicitation, there is a range of prototyping techniques and a number of points in the process where prototype validation may be appropriate. The advantage of prototypes is that they can make it easier to interpret the software engineer’s assumptions and, where needed, give useful feedback on why they are wrong. For example, the dynamic behavior of a user interface can be better understood through an animated prototype than through textual description or graphical models. The volatility of a requirement that is defined after prototyping has been done is extremely low because there is agreement between the stakeholder and the software engineer—therefore, for safety-critical and crucial features prototyping would really help. There are also disadvantages, however. These include the danger of users’ attention being distracted from the core underlying functionality by cosmetic issues or quality problems with the prototype. For this reason, some advocate prototypes that avoid software, such as flip-chart-based mockups. Prototypes may be costly to develop. However, if they avoid the wastage of resources caused by trying to satisfy erroneous requirements, their cost can be more easily justified. Early prototypes may contain aspects of the final solution. Prototypes may be evolutionary as opposed to throwaway.

SWEBOK Ch. 1 section 6.2

Prototype - software - A term currently with multiple meanings. A “rapid prototype” is usually a software requirements demonstration model, which provides a simulated representation of the software functionality and operator interface. The model facilitates early buyer-developer agreement on the design approach. A software prototype may also be a technical demonstration model. Except with “Evolutionary Prototypes,” the code is usually discarded once the model has served its purpose. (Forsberg, Mooz, Cotterman 2005, p 432)

https://www.sebokwiki.org/wiki/Prototype_(glossary)

• A wireframe is a rough sketch about how a website/app will look like. It is usually presented with gray lines, boxes, colors and placeholders. It is similar to the blueprint of a building.

• A mockup is a static wireframe with much more UI and visual details. A mockup is similar to a real-life building model.

• A prototype is dynamic (clickable) mockup.

You might be able to enhance your mockup and make it clickable using the same software you used to create your mockup.

If you want an evolutionary prototype, make it with whatever you will use for your proposed solution (e.g. make an actual web site or use Scene Builder, Android Studio, Visual Studio, etc.).

In the References section of your Requirements Specification, add a link to something demonstrating the functionality of your prototype.

This could be one or more of the following:

• a link to a website

• a proprietary file format for specialized software that I could install (identify the software)

• an exe or runnable jar (ideally in a GitHub repository with code)

• a video demonstration or animated gif (ideally in a GitHub repository README)

• Add to Jira Notes

• Complete Elicitation Report

Share your analyzed requirements with applicable stakeholders to validate that their needs and expectations have been adequately captured and expressed.

Although with Agile it could still be revisited, at this point, you have completed the Stakeholder needs and requirements definition process (29148 6.3). It would be possible to make a StRS but one is not required for this class.

In your Specification Notes blog post...

• Create a heading 1 named Stakeholder Requirements Specification (StRS) using the dropdown box at the top left

  • Create a heading 2 for each of the following and provide the corresponding information (REQ.rsd.1):

    • General description

    • Audience

    • Structure

    • Attributes

    • Standards

Submit a link to your overview page.

Overview

• Describe product perspective - write summary

• Refine scope - name, what it does (operational concept), objectives

Details

Read

• 29148-2018 6.4.3.2

Tasks

• Define the functional boundary of the system [software system or element] in terms of the behaviour and properties to be provided.

• Define the system[/software] requirements definition strategy.

• Identify and plan for the necessary enabling systems or services needed to support system[/software] requirements definition.

• Obtain or acquire access to the enabling systems or services to be used.

In your Requirements Specification, at the top

• Fill in the heading 2 named Scope

  • identify the software product(s) to be produced by name (e.g., Host DBMS, Report Generator, etc.);

  • explain what the software product(s) will do; Write at least a couple of paragraphs.

  • describe the application of the software being specified, including relevant benefits, objectives and goals;

    • include a Jira table of objectives

  • be consistent with similar statements in higher-level specifications

• Fill in the heading 3 named Product perspective

  • Define the system's relationship to other related products. Write at least a paragraph.

  • If the product is an element of a larger system, then relate the requirements of that larger system to the functionality of your product.

  • If the product is an element of a larger system, then identify the interfaces between the product and the larger system of which the product is an element.

  • Describe how the software operates within the following constraints:

  • a) system interfaces;

  • b) user interfaces;

  • c) hardware interfaces;

  • d) software interfaces;

  • e) communications interfaces;

  • f) memory;

  • g) operations;

  • h) site adaptation requirements; and

  • i) interfaces with services

Submit a link to your overview page.

• It will look like https://username.atlassian.net/wiki/spaces/projectkey/overview

Overview

• Hand sketch context diagram

• Make list of product functions

• Specify system requirements related to...

  • External interfaces

  • Functions

  • Usability

  • Performance

  • Logical database

  • Design constraints

• System attributes (link to other issues for traceability)

Details

You have previously defined stakeholder requirements, now define system / software requirements.

Read

1. SWEBOK Ch. 1 section 7.3

2. SWEBOK Ch. 1 section 7.4

3. 29148-2018 5.2.5

4. 29148-2018 5.2.6

5. 29148-2018 6.3

6. 29148-2018 6.4

7. "Software Requirements" Weigers book Chapter 11 Writing excellent requirements

8. The specification page on the course web site.

9. Your Requirements Notes / One Good Requirement

Tasks

• Define each function that the system [software system or element] is required to perform.

• Identify required states or modes of operation of the software system.

• Define necessary implementation constraints.

• Identify system requirements that relate to risks, criticality of the system, or critical quality characteristics.

• Identify requirements that relate to risks, criticality of the software system, or critical quality characteristics.

• Define system requirements and rationale.

• Define system/software requirements and requirements attributes, including the following:
  i) Data elements, data structures and formats, and database or data retention requirements;
  ii) User interfaces and user documentation (information for users) and user training;
  iii) Interfaces with other systems and services;
  iv) Functions and non-functional characteristics, including critical quality characteristics and cost targets;
  v) Transition of operational processes and data from existing automated and manual systems, migration approach and schedule, software installation and acceptance of the product; and
  vi) Requirement attributes, such as rationale; priority; traceability to software system elements; test cases, and information items; methods of verification; inclusion in approved baselines; and evaluated risk.

Write more requirements (at least 10, possibly many more) for your project focusing on the system.

Consider requirements related to functions, performance requirements, usability requirements, interface requirements, and logical database requirements. Consider the bullet points above.

In Jira, using the Requirement issue type created in Activity 6.3.3.5, add requirements in the Backlog. Type the requirement statement in the box that comes up after clicking the + in the Backlog. This is the Summary field. Each requirement should adhere to the Characteristics of individual requirements from 5.2.5.

For each requirement you add, click on it to bring up the properties / attributes. Review 29148-2018 5.2.8 Requirements attributes.

• At a minimum, include the following attributes:

  • Identification: done automatically by Jira

  • Version Number: done automatically by Jira in Activity - History

  • Stakeholder Priority: will be set in a later assignment

  • Rationale: write a description and / or link to a user story. Use the Description and / or a Label to identify the source of the requirement. Most functional requirements can be associated with a user story. For the sake of this assignment, link a user story to at least one requirement. To do this, click the chain icon next to the requirement. Each user story is likely to correspond to at least one, and possibly multiple requirements.

  • Type: in Jira, we are using the Issue Type Requirement, in a later assignment you will use the Labels field to identify the type of requirement.

• Optionally, if appropriate, set the following attributes:

  • Owner: in Issue Settings, add a People field named Owner

  • Risk

  • Difficulty

Add at least 5 system / software related constraints using the Constraint issue type.

Constraints restrict the design solution or implementation of the systems engineering process.

Sources of constraints include:

• Specific technologies, tools, languages, and databases that must be used or avoided.

• Restrictions because of the product’s operating environment or platform, such as the types and versions of web browsers or operating systems that will be used.

• Required development conventions or standards. (For instance, if the customer’s organization will be maintaining the software, the organization might specify design notations and coding standards that a subcontractor must follow.)

• Backward compatibility with earlier products and potential forward compatibility, such as knowing which version of the software was used to create a specific data file.

• Limitations or compliance requirements imposed by regulations or other business rules.

• Hardware limitations such as timing requirements, memory or processor restrictions, size, weight, materials, or cost.

• Physical restrictions because of the operating environment or because of characteristics or limitations of the users.

• Existing interface conventions to be followed when enhancing an existing product.

• Interfaces to other existing systems, such as data formats and communication protocols.

• Restrictions because of the size of the display, as when running on a tablet or phone.

• Standard data interchange formats used, such as XML, or RosettaNet for e-business.

Examples of constraints

• CON-1. The user clicks at the top of the project list to change the sort sequence. [specific user interface control imposed as a design constraint on a functional requirement]

• CON-2. Only open source software available under the GNU General Public License may be used to implement the product. [implementation constraint]

• CON-3. The application must use Microsoft .NET framework 4.5. [architecture constraint]

• CON-4. ATMs contain only $20 bills. [physical constraint]

• CON-5. Online payments may be made only through PayPal. [design constraint]

• CON-6. All textual data used by the application shall be stored in the form of XML files. [data constraint]

Examples of constraints include:

• interfaces to already existing systems (e.g., format, protocol, or content) where the interface cannot be changed,

• physical size limitations (e.g., a controller shall fit within a limited space in an airplane wing),

• laws of a particular country,

• available duration or budget,

• pre-existing technology platform,

• user or operator capabilities and limitations

• a) System interfaces;

• b) User interfaces;

• c) Hardware interfaces;

• d) Software interfaces;

• e) Communications interfaces;

• f) Memory;

• g) Operations;

• h) Site adaptation requirements.

In your Requirements Specification, complete the Product functions section.

Submit a link to your overview page.

Overview

• Classify

  • Functional or Nonfunctional

  • Priority

• Make conceptual model (context diagram) using software

• Perform requirements negotiation / "conflict resolution"

• Apply critical thinking (use Elder Paul Elements of Thought)

• Quality Checklist from MITRE (validation)

Details

Read

1. 29148:2018 6.4.3.4

2. MITRE Development of System-Level Requirements starting on page 353

3. SWEBOK Ch. 1 section 4.2

4. 29148:2018 9.6.4

5. 29148:2018 9.6.11

6. Data Flow Diagram agilemodeling

7. Data Flow Models page on the course web site

Review

1. SWEBOK Ch. 1 section 4.1

2. SWEBOK Ch. 1 section 7.3

3. Refer to SWEBOK Ch. 1 sections 1.2, 1.3, and 1.4

4. 29148-2018 5.2.6

5. 29148-2018 5.2.7

6. 29148-2018 5.2.8

7. "Software Requirements" Weigers book Chapter 16: First things first: Setting
   requirement priorities

Tasks

• Analyze the complete set of system[/software] requirements.

• Define critical performance measures that enable the assessment of technical achievement.

• Feed back the analyzed requirements to applicable stakeholders for review.

• Resolve system requirements issues.

• Identify and resolve issues, deficiencies, conflicts, and weaknesses within the complete set of requirements.

Requirements Classification

You have already analyzed the stakeholder requirements in Activity 6.3.3.6. Do the same tasks with the system/software requirements.

In the properties / attributes for each new system requirement...

• Set a Priority using the arrows (1-5). (see 5.2.8.2)

• Apply a label: functional or nonfunctional (see SWEBOK 1.3).

• If applicable, apply one of the following labels: Performance, Usability, Interface, Database.

Remember, requirements may also be classified based on...

• whether the requirement is derived from one or more high-level requirements or an emergent property, or is being imposed directly on the software by a stakeholder or some other source. (see SWEBOK 1.4)

• whether the requirement is on the product or the process (see SWEBOK 1.2)

• other attributes as described in 5.2.8.3

Conceptual Modeling - Context Model

From 29148-2018 9.6.4:

Define the system's relationship to other related products.

If the product is an element of a larger system, relate the requirements of that larger system to the functionality of your product.

If the product is an element of a larger system, identify the interfaces between your product and the larger system of which the product is an element.

From 29148-2018 9.6.11:

Define all inputs into and outputs from the software system.

Each interface defined should include the following content:

a) Name of item;

b) Description of purpose;

c) Source of input or destination of output;

Use one of the suggested tools on the course web site to create a Level 0 Data Flow Diagram (also known as a Context Diagram) for your software to be developed.

Your diagram should have one process node and generalize the function of the entire system in relation to external entities.

Optionally, nest next level diagrams.

• In the heading 3 named Product perspective

  • Add a block diagram / context diagram showing the major elements of the larger system, interconnections, and external interfaces can be helpful.

Formal Analysis

Verify that...

• each requirement uses the construct in 5.2.4

• each requirement conforms to 5.2.5

• the set adheres to 5.2.6

• each requirement adheres to 5.2.7

Go through the MITRE System-Level Requirements Checklist (p. 354-356)

Share your analyzed requirements with applicable stakeholders to validate that their needs and expectations have been adequately captured and expressed.

Add to your Analysis Notes

• In the General section

  • One paragraph describing what a context diagram is in general and why it is beneficial.

• In the My Project section

  • Within the Conceptual Modeling heading add a heading 3 named Context Diagram / Level 0 DFD

    • One paragraph describing the process you took to create your diagram including what software you used.

    • Add your context diagram

• • Within the Formal Analysis section copy / paste MITRE Table 1. System-Level Requirements Checklist (p. 354-356) into your page. You can slightly modify the checklist to make it more applicable to software requirements if you would like. Go through each checklist item for your set of requirements and check the box if your set of requirements conforms.

    • It will be a bit of a nuisance to do this the first time but you can reuse it and it will be useful to you in the future.

Submit a link to your overview page.

Overview

• Make RTM of high level objectives and requirements

• Describe SyRS

• Add to Tool Presentation

• Complete Analysis Report

Details

Read

• 29148

  • 6.2.3.6 Manage the Business or Mission Analysis

  • 6.3.3.7 Manage the stakeholder needs and requirements definition

  • 6.4.3.5 Manage system[/software] requirements

• Weigers book

  • Tying everything together section, p. 180

  • Chapter 29 Links in the requirements chain

• Traceability Matrix wikipedia

Tasks

• Obtain explicit agreement on the system[/software] requirements.

• Maintain traceability of the system[/software] requirements.

• Provide key [artifacts and] information items that have been selected for baselines.

Obtain explicit agreement on the system[/software] requirements.

• Read the assignment for Activity 6.5.3.2-3.

• Schedule a requirements review with a classmate and your sponsor for that assignment.

Maintain traceability of the system[/software] requirements.

• "In software development, a traceability matrix (TM) is a document, usually in the form of a table, used to assist in determining the completeness of a relationship by correlating any two baselined documents using a many-to-many relationship comparison. It is often used with high-level requirements (these often consist of marketing requirements) and detailed requirements of the product to the matching parts of high-level design, detailed design, test plan, and test cases." wikipedia

• There are many ways to trace requirements and many different ways to create a requirements traceability matrix (RTM). For this assignment you need to link your requirement statements and user stories to their higher level requirements. (29148-3.1.24)

• In your Requirements Specification, at the bottom of the Specific requirements section, create a heading 2 for Supporting information

• Create a RTM as a table in Confluence. Similar to Table 29-1 in the book, put Jira Objective issues in the first column as links. In the second column, add Jira Requirements and Stories as links. There should be multiple requirements and stories associated with each objective. Optionally, add columns for Design element, Code element, and/or Test. Another example

Provide key [artifacts and] information items that have been selected for baselines.

Although with Agile it could still be revisited, at this point, you have completed the System [System/Software] Requirements definition process (29148 6.4). It would be possible to make a SyRS but one is not required for this class.

• In your Specification Notes blog post...
  

  • Create a heading 1 named System Requirements Specification (SyRS) using the dropdown box at the top left

    • Create a heading 2 for each of the following and provide the corresponding information (REQ.rsd.1):

      • General description

      • Audience

      • Structure

      • Attributes

      • Standards

Submit a link to your overview page.

Read

• 29148-2018 6.5.2.2 Prepare for verification

• 29148-2018 6.5.2.3 Manage results of verification

• 29148-2018 9.6.19 Verification

• SEBOK System Verification

• MITRE Systems Engineering Guide p 356

• The four fundamental methods of requirement verification

• "Software Requirements" Wiegers book Chapter 17: Validating the requirements

Tasks

• Select appropriate verification methods or techniques and associated criteria for every verification action.

• Maintain traceability of the verified [software] system elements.

The acronym V&V is often used for checking compliance with requirements.

In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?"

On the other hand, software validation is: "Was X what we should have built? Does X meet the high level requirements?"

Create a new Blog post named Validation Notes.

• Create a heading 1 for Requirements Validation in General

  • Create a heading 2 for each validation technique listed in SWEBOK Ch. 1 section 6.

    • Describe each technique in your own words.

  • Create a heading 2 for each reading source. Add notes from each reading.

    • At a minimum, summarize and cite the SEBOK System Verification page and include its Table 3. Verification Techniques.

• Create a heading 1 for Requirements Validation in My Project

  • Create a heading 2 for Verification - define verification as compared to validation

Make a Verification Cross Reference Matrix (VCRM).

Provide the verification approaches and methods planned to qualify the software.

• Edit the Requirement issue type to add a new Field of type Dropdown.

• Name the field Verification Approach

• Set the Description to "How it will be proven to stakeholders that the software meets this requirement"

• Add options for "Inspection", "Analysis", "Demonstration", and "Test"

  • Although there are other verification approaches, these are considered the main four and are usually abbreviated IADT. Most requirements will have one of these validation methods, but sometimes a requirement will have more than one.

• Go through all of your requirements and really think about how you will be able to prove to stakeholders that the requirement was met after the software is built and set the Verification Approach field.

In your Requirements Specification, under the Specific Requirements section

• Add a heading 1 named Verification.

• Insert your requirements using /jira. Tip: use type = requirement in the search box

• Edit the table by clicking the pencil icon that appears below it when selected

  • Click Display options

    • Leave the Maximum issues box empty to get all issues

    • In Columns to display, click the X next to any column to remove it and click an empty area in the box to bring up other columns to add.

      • Set the table to display Key, Summary, and Verification Approach, in that order.

Ideally, a comprehensive verification plan would include specific details like expanded test criteria descriptions to ensure that there is no disagreement later in the program. This can include describing the number of trials, statistical criteria to be used, conditions of the test such as simulated inputs, etc.

Verification approaches for all system performance and sustainability requirements should be complete and appropriate. Every requirement must have a verification method identified. If a requirement cannot easily be verified by a direct inspection, measurement, or one-time demonstration of the requirement, the verification requirement should include an expanded test criteria description to ensure that there is no disagreement later in the program. This can include describing the number of trials, statistical criteria to be used, conditions of the test such as simulated inputs, etc.

MITRE Systems Engineering Guide p 356

Add a link to your Validation Notes in your overview page.

Submit a link to your overview page.

Overview

• Not just done at the end

• Review prototype

• Review quality checklists

• Conduct Requirements Review

  • Stakeholders - validate correctness

    • Thank them and provide them with SRS when complete

  • Technical - have a classmate validate conformance and quality

• Describe and create SRS

• Complete Tool Presentation

• Complete Specification Report

• Complete Validation Report

Details

Read

1. SWEBOK Ch. 1 section 6.1

2. SWEBOK Ch. 1 section 6.2

3. SWEBOK Ch. 15 section 5.3

4. 29148-2018 6.4.3.4

5. 29148-2018 6.4.3.5

6. Software Requirements 3rd Edition Ch. 17: Validating the requirements

Tasks

• Obtain explicit agreement [with designated stakeholders] on the stakeholder requirements.

• Maintain traceability of stakeholder needs and requirements.

• Obtain explicit agreement on the system[/software] requirements.

• Maintain traceability of the system[/software] requirements.

• Provide key [artifacts and] information items that have been selected for baselines.

"Validation isn’t a single discrete phase that you perform after eliciting and documenting all the requirements. Some validation activities, such as incremental reviews of the growing requirements set, are threaded throughout the iterative elicitation, analysis, and specification processes. Other activities, such as formal inspections, provide a final quality gate prior to baselining a set of requirements." - Software Requirements 3rd Edition

Perform requirements validation to establish with stakeholders that their requirements are expressed correctly by conducting a requirements review.

Reviews can be conducted on individual requirements, a set of requirements, documents, and more.

Have a classmate check your set of requirements for errors, mistaken assumptions, lack of clarity, and deviation from standard practice.

Have your sponsor check your set of requirements for errors, mistaken assumptions, and lack of clarity.

Explain and obtain agreement to the proposals to resolve conflicting, impractical and unrealisable stakeholder requirements. Take notes during the review.

In your Validation Notes

• • In the Requirements Validation in My Project section

  • Add a heading 2 for Requirements Reviews

  • Add a heading 3 for Requirements Review (requirements expert)

    • Provide evidence of sign off on the requirements by a classmate regarding adherance to standard from an email confirmation or some other means.

    • Describe the process you took and the results.

  • Add a heading 3 for Requirements Review (sponsor)

    • Provide evidence of sign off on the requirements by stakeholders from an email confirmation or some other means.

    • Describe the process you took and the results.

  • Add a heading 2 for Prototype

    • Include an animated gif or video demonstrating your prototype. (from another assignment)

    • Describe how your prototype was used to validate requirements.

Note: there is a Jira Marketplace app for Sign Off and Approval

Although with Agile it could still be revisited, at this point, you have completed the Requirements engineering activities in other technical processes (29148 6.5). It is now possible to make a SRS.

In your Specification Notes blog post...

• Create a heading 1 named Software Requirements Specification (SRS)

  • Create a heading 2 for each of the following and provide the corresponding information (REQ.rsd.1):

    • General description

    • Audience

    • Structure

    • Attributes

    • Standards

• Create a heading 1 named My SRS

  • Describe what you did to create your SRS.

Submit a link to your overview page.

• In General (lower order thinking)

  • Who, what, when, why, how

• In My Project (higher order thinking)

  • Summary

• In General (lower order thinking)

  • SWEBOK Ch. 1 section 3

    • Sources

    • Techniques

• In My Project (higher order thinking)

  • Stakeholder identification

  • Interview questions and answers

  • Observation notes

  • Mockup

  • User stories

  • FGCUScholars 3. Demonstrate proficiency in information literacy skills.

    • ABET 7. Acquire and apply new knowledge as needed, using appropriate learning strategies at an intermediate level.

  • ACM/IEEE 4 and SEEK REQ.er. Elicit requirements from multiple sources using multiple techniques and describe the fundamental challenges of and common techniques used for requirements elicitation.

• In General (lower order thinking)

  • SWEBOK Ch. 1 section 4

• In My Project (higher order thinking)

  • Classified and prioritized requirements table

    • ACM/IEEE 6. Identify both functional and non-functional requirements in a given requirements specification for a software system.

  • Use Cases and Use Case Diagram and description

    • ACM/IEEE 1. List the key components of a use case or similar description of some behavior that is required for a system.

  • Context Diagram and description

  • FGCUScholars 2. Demonstrate proficiency in critical thinking skills.

  • ABET 2. Apply engineering design to produce solutions that meet specified needs with consideration of public health, safety, and welfare, as well as global, cultural, social, environmental, and economic factors at an intermediate level.

  • ABET 4. Recognize ethical and professional responsibilities in engineering situations and make informed judgments, which must consider the impact of engineering solutions in global, economic, environmental, and societal contexts at an intermediate level.

• In General (lower order thinking)

  • SWEBOK Ch. 1 section 5

  • 29148-2018 5.2.5-8

  • 29148-2018 sections 7-9, Annex A, Annex B

• In My Project (higher order thinking)

  • Summary of creation of BRS and SRS

  • FGCUScholars 1. Demonstrate proficiency in writing skills.

• In General (lower order thinking)

  • SWEBOK Ch. 1 section 6

• In My Project (higher order thinking)

  • Prototype summary

  • Evidence of requirements reviews

    • Quality checklists

    • ACM/IEEE 7. Conduct a review of a set of software requirements to determine the quality of the requirements with respect to the characteristics of good requirements.

  • ACM/IEEE 2. Describe how the requirements engineering process supports the elicitation and validation of behavioral requirements. (reference and include use cases)

• Identification

• Introduction (Business purpose, Business scope, Business Overview, Definitions, Major stakeholders)

• References

• Business management (Business environment, Mission, goals, and objectives, Business model, Information environment)

• Business operations (Business processes, Business operational policies and rules, Business operational constraints, Business operational modes, Business operational quality, Business structure)

• Preliminary operational concept of proposed system (Preliminary operational concept, Preliminary operational scenarios)

• Preliminary life-cycle concepts (Preliminary acquisition concept, Preliminary deployment concept, Preliminary support concept, Preliminary retirement concept)

• Project Constraints

• Appendix (Acronyms and abbreviations, Assumptions)

• Page Properties

• Objective

• Success metrics

  • Objectives

• Assumptions

• Requirements

  • User stories

• User interaction and design

  • Mockup

• Open Questions

• Scope

• Identification - Title and Revision notice (project name, version number of the document, date of release)

• Front matter - a table of contents, a list of figures, a list of tables

• Introduction - just a heading

  • Purpose - why make it?

  • Scope - name, what it does (operational concept), objectives

  • Product overview - just a heading

    • Product perspective - context diagram and written summary

    • Product functions

    • User characteristics

    • Limitations - constraint issues

  • Definitions - any words or phrases that have special meaning beyond normal dictionary definitions

• References - documents from research, results of elicitation, prototype

• Specific requirements - just a heading

  • Formal requirement statements (functional, performance, usability, interface, database, design, attributes)

  • Supporting Information

    • Elicitation results (user stories, interview questions and answers, observation notes, etc.)

    • Use cases and use case diagram

    • RTM

• Verification - just a heading

  • Verification Cross Reference Matrix (VCRM) and description of verification techniques

• 5. Appendices - just a heading

  • Assumptions and dependencies

  • Acronyms and abbreviations