Tag Archives: Confluence

How to Discover Requirements

Problem:

You want to quickly capture and analyze requirements for a project developed using Scrum or Kanban method however misunderstandings happen too frequently among your team members.

Suggestion:
  1. Define and get agreement about terminologies (terms).
  2. Decompose a user story into end-to-end workflow with screenshots or mock-ups.
  3. Define test scenarios for a user story.
  4. Use a tool such as Confluence pages for documenting and clarifying user story.
  5. If the problem still persists then try elaborating a user story to a use case, and/or a flow chart, and/or a domain model, and/or mind map, and/or a sequence diagram.
  6. If possible always use face-to-face meetings for communication.

Topic 14 – Software Project Management

Why do I need to learn about software project management?

Knowing how to create software does not mean that you will create software SUCCESSFULLY. Creating software successfully means that you satisfy all customer’s REQUIREMENTS ON TIME, ON BUDGET with HIGH QUALITY while making both the customer and yourself HAPPY. Especially, your software must create REVENUE for the customer.

Have you ever wondered why many software projects failed; why Microsoft, Oracle, Google, Apple, Amazon and IBM abandoned many projects? Software project management will provide you knowledge so that you could improve the success probability of your software projects and mitigate all the project risks.

What can I do after finishing learning about software project management?

You will know how to plan a project, including scoping, estimating time and resources, creating a schedule or an adaptive release plan, identifying and responding to risks.

You will know how to create software using the mindset of a specific methodology (i.e. Waterfall, Rational Unified Process, Iterative and Incremental Development, Agile Methods, Scrum, Extreme Programming, Kanban, PMI, PRINCE2).

You will know how to perform project configuration management, how to combine development and operations to release software faster, how to control project changes, how to report project status, how to control product and process quality.

You will know how to collaborate with others to create software, how to motivate your team members.

Uh-oh! I am a developer. I do not want to be a project manager. Do I really need to know about project management?

If you have a doubt about the usefulness of project management knowledge then just review the situations below. If you can overcome all of them then congratulation, you already have enough project management knowledge that a developer needs.

– You are asked by your manager when you can finish your tasks. Unfortunately, the tasks are new to you. The requirements are vague. It is even worse that you have not found technical solutions for them.

– You are required to finish a task requiring a collaboration with other team members. Conflicts arise frequently. You do not want to work with them anymore but you still have to complete the task.

– You cannot complete a task on time due to many incidents.

– You are given only a project idea and asked to create a product. The difficulty is that you do not know where to start.

– Most of your projects cannot be complete on time and on budget and you do not know what are the root cases.

– Most of your customers do not want to partner with your team again although their projects were finished on time with high quality by your team.

Alright! What should I do now?

First,  please read this book to get familiar with software project management concepts: Jennifer Greene and Andrew Stellman (2005). Applied Software Project Management. O’Reilly.

After that, please read this book to learn how to estimate effort, time and cost for a software project: Steve McConnell (2006). Software Estimation: Demystifying the Black Art. Microsoft Press.

After that, please read this book to learn the principles of software project management: Frederick P. Brooks, Jr. (1995). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley Professional.

After that, please read the two books below to learn how to deal with the human side of a software project:

After that, please read this book to learn how to deal with software project risks: Tom DeMarco and Timothy Lister (2003). Waltzing with Bears: Managing Risks On Software Projects. Dorset House.

After that, please read the books below to learn how to manage software project activities using the Unified Process:

After that, please read the books below to learn how to manage software project activities using the Scrum process:

After that, please read this book to learn how to manage requirements in an Agile project: Dean Leffingwell (2011). Agile Software Requirements. Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional.

After that, please read this book to learn how to estimate cost, effort, and duration, and how to create and manage a plan for an Agile project: Mike Cohn (2005). Agile Estimating and Planning. Pearson Education.

After that, please read this book to learn how to apply Extreme Programming techniques in an Agile project:  Kent Beck and Cynthia Andres (2004). Extreme Programming Explained: Embrace Change. 2nd Edition. Pearson Education.

After that, please read the books below to learn how to carry out software project management activities with an Agile mindset:

After that, please read the books below to learn how to manage software project activities using the Kanban method:

After that, please read this book to learn how to perform software configuration management activities: Jessica Keyes (2004). Software Configuration Management. Auerbach Publications.

After that, please read this book to learn how to release software continously: Len Bass, Ingo Weber and Liming Zhu (2015). DevOps: A Software Architect’s Perspective. Pearson Education.

After that, please read the books below to become familiar with the knowledge areas and techniques developed by the Project Management Institute (PMI):

After that, lease read the two books below if you are interested in obtaining a PMP certificate:

After that, please read this book to review classical methods and techniques of software development: Steve McConnell (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press. The information in this book may help you address specific problems, such as unrealistic deadlines, frequent delays, and unclear or changing requirements.

After that, please read this book to review approaches to software project management, especially when organizational-level processes and practices establish the platform on which a software project is managed: Murali K. Chemuturi and Thomas M. Cagley Jr. (2010). Mastering Software Project Management: Best Practices, Tools and Techniques. J. Ross Publishing.

Terminology Review:

  • Project Initiation
  • Scope Management
  • Agile Requirements
  • Waterfall
  • Rational Unified Process (RUP)
  • Enterprise Unified Process
  • Agile Methods
  • Extreme Programming (XP)
  • Scrum
  • Kanban
  • Work-in-Progress (WIP)
  • Software Estimation
  • Agile Estimating
  • Project Planning
  • Gantt Chart
  • Cost Management
  • Agile Planning
  • Configuration Management
  • CI/CD/DevOps
  • Project Monitoring and Control
  • Time Management
  • Peopleware
  • Team Management
  • Team Motivation
  • Software Quality
  • Agile Retrospectives
  • Quality Management
  • Risk Management
  • Software Project Management
  • Software Process
  • Project Management Professional (PMP)
  • CMMI

After finishing software project management, please click on Topic 15 – Advanced Database Management Systems to continue.

Topic 10 – Software Requirements

Why do I need to learn about software requirements?

Your software can only be successful if it helps people do their work better, faster, with lower cost. In order to achieve this objective, it must fulfill the need of various users. In order to fulfill users’ needs you need to be able to identify their context, problems and needs, then propose software solutions for their issues.

Your software solutions must be built based on its users’ requirements that help them solve their problems. So you need to be able to collect, document, manage and validate their requirements. Software requirements engineering will provide you knowledge for completing these tasks.

Do not waste your time to create software that NO ONE will use. Your software will only become useful if its requirements are correctly engineered.

What can I do after finishing learning software requirements engineering?

You will know how to elicit, document, manage and validate software requirements so that they can be used for creating your software.

Hmm! Is it really useful?

If you still have a doubt about its usefulness then you can delay learning about software requirements until you are tasked to create a software system but you do not know where to begin or what are the inputs for your coding.

Another scenario that may suggest that you should come back to this topic is when you create a software system but unfortunately you find that no one wants to use it.

Alright! What should I do now?

First, please read this book to learn how to develop enterprise software requirements step by step: Suzanne Robertson and James Robertson (2012). Mastering the Requirements Process. Addison Wesley Professional.

After that, please read this book to learn about techniques for engineering software requirements: Karl Wiegers and Joy Beatty (2013). Software Requirements. Microsoft Press.

After that, please read this book to learn how to use models for representing software requirements: Joy Beatty and Anthony Chen (2012). Visual Models for Software Requirements. Microsoft Press.

After that, please read this book to learn how to write use cases effectively: Alistair Cockburn (2001). Writing Effective Use Cases. Addison-Wesley.

After that, please review this standard so that you could create a quality software requirements specification for projects require high formal specification: ISO/IEC/IEEE 29148:2011(E).

After that, please read this book to learn how to use user stories for documenting and communicating requirements: Mike Cohn (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional.

After that, please read this book to learn how to discover the real problems that need to be solved: Jeff Patton and Peter Economy (2014). User Story Mapping. O’Reilly Media.

After that, please read this book to learn how to manage and communicate requirements across large teams: Dean Leffingwell (2011). Agile Software Requirements. Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional.

After that, please read this book to review the core concepts and gain insightful advice when facing challenges in discovering requirements: Karl Wiegers and Candase Hokanson (2023). Software Requirements Essentials. Addison-Wesley Professional.

After that, please read this book to learn how to manage requirements for large government projects: George Koelsch (2023). Hardware and Software Projects Troubleshooting – How Effective Requirements Writing Can Save the Day. Apress.

After that, please read this book if you want to obtain a PMI-PBA certificate: Project Management Institute (2015). Business Analysis for Practitioners – A Practice Guide. Project Management Institute.

Terminology Review:

  • Elicitation Techniques: Interviews, Questionnaires, Group Meetings, Personas, Brainstorming, Document Analysis, Apprenticing, Observations, User Interface Analysis, System Interface Analysis, Reverse Engineering.
  • Business Requirements.
  • Stakeholders.
  • Sponsors.
  • Customers.
  • Users.
  • Business Analysts.
  • Terminologies, Terms.
  • Problems.
  • Business Goals.
  • Evaluator Pitch.
  • Work Context Diagrams.
  • Executive Summary.
  • User Requirements.
  • Glossary.
  • Business Rules.
  • Business Use Cases.
  • Scenarios, Business Workflows, Business Processes.
  • Storyboards.
  • Process Flows.
  • Activity Diagrams.
  • Swimlane Diagrams.
  • The Brown Cow Model.
  • Business Rules.
  • Domain Models.
  • Business Data.
  • Entity Relationship Diagrams.
  • Data Flow Diagrams.
  • State Models.
  • Features.
  • Feature Model.
  • Feature Tree.
  • Project Vision.
  • Software Requirements.
  • Functional Requirements.
  • Use Cases.
  • Non-Functional Requirements.
  • Software Requirements Specification.
  • User Stories.
  • Business Values.
  • Story Map.
  • Product Backlog.
  • User-Interface Prototypes.
  • User Interface Flow Diagrams.
  • ISO/IEC/IEEE 29148:2011(E).

After finishing software requirements, please click on Topic 11 – Software Construction to continue.