Tag Archives: Domain Model

Software Construction, Software Requirements

How to Quickly Capture and Analyze Requirements for Building a Prototype or Proof of Concept?

Leave a comment
Motivation:

You need to quickly capture and analyze requirements for building a prototype or proof of concept for an enterprise system.

Suggestion:
  1. Capture any artifacts related to a business need. They may be some emails, presentation slides, a proposal document, a legacy system, some similar systems, a feature list or an initial requirement specification.
  2. Define terminologies (terms), build a background and context around the terminologies, expand the terminologies into business roles, business workflows, business components, business entities (objects), and business artifacts as much as possible.
  3. Identify the main stakeholders (roles) who will interact with the system (e.g. Guest, Admin, Developer, User, etc.) and their corresponding business problems or needs (i.e. their motivation of using the software system), and their current business workflows. Create as many scenarios (real world or domain business workflows) as possible. Create a domain model (a model of real world or domain entities, their properties and their relationships) if necessary.
  4. If there is an existing or similar system then identify the core components that each stakeholder will interact with (e.g. Accounts, Profiles, Reporting, APIs, Lessons, Videos, etc.) and their corresponding purposes.
  5. Identify the main tasks that each stakeholder will perform (e.g. Register an Account, Log in System, Create/Edit Profile, Create a Bucket, Generate an API Key, Create/Edit/Delete a Lesson, Create/Edit/Delete a Video, View Bandwidth, etc.).
  6. Identify the inputs and outputs and create mock-ups (sketches) or capture similar screens for each task. The quickest way to create a mock-up is to find similar existing screens in your system or external systems, and modify them. You can also search for templates of similar features in the Internet, and modify them. You can also brainstorm a  new one if you are good at creativity and imagining.
  7. Build or draw a prototype demonstrating 2 or 3 critical end-to-end workflows (An end-to-end workflow is a sequence of tasks that solves a real world problem completely). Contrast a current business workflows with the end-to-end workflows demonstrated by the prototype. The quickest way to create a prototype is to find similar existing workflow of of your system or external systems, and modify them. You can also repurpose a business workflow for a prototype. You can also brainstorm a  new one if you are good at creativity and imagining.
  8. Implement a proof of concept related to the 2 or 3 critical end-to-end workflows.
  9. For a complicated system, you may need to implement a proof of concept, build a prototype, and create a work break down structure or product backlog in parallel to ensure that the requirements are technologically and economically feasible.

 

 

Software Design, Software Engineering Curriculum

Topic 12 – Introduction to Software Design

Leave a comment

Why do I need to learn about software design?

What will you do if you are asked to build a house?
You will need to sketch its first and build the house based upon the sketch. Otherwise you may build a house that may collapse in a few weeks or cannot be decorated due to errors.

The situation is similar when you create software. You need to plan how you will build it first by deciding how many components and objects will be used for constructing to solve at least a core problem, what are their responsibility, how they work together, how data will be organized, how data will be flowed within these components, how users will interact with your application, how these components will be deployed.

Software design knowledge will guide you how to do these tasks.

What can I do after finishing learning software design?

You will know how to create a design for an application including static and dynamic structure, data organization, business processing workflows.

Is is really useful? I feel that you can write the code right after having the requirements and I could refactor my code when needed.

That’s great if you can do it like that. You may just return to this topic

(i) when you do not know how to write the code for a feature or

(ii) when you cannot refactor your code because only a small change breaks the whole application or

(iii) when you write a software system together with 20 other developers and you do not know how to integrate results of all the developers into one solution or (iv) when you software system serves 20 users simultaneously very well but it stops when serving 2,000 users simultaneously and you do not know how to fix it.

Alright! What should I do now?

Software design requires a lot of reading. Each application type (enterprise systems, games, intelligent systems) require specific design knowledge. At this point we focus only on the basic elements of software design.

In order to get familiar with software design please read these 3 books below in parallel:
– Grady Booch et al. (2005). The Unified Modeling Language User Guide. Addison Wesley Professional
– Craig Larman (2004). Applying UML And Patterns. 3rd Edition. Prentice Hall
– Robert C. Martin (2003). Agile Software Development – Principles, Patterns, and Practices. Pearson

After that please read this Erich Gamma et al (1994). Design Patterns Elements Of Reusable Object Oriented Software. Addison-Wesley Professional book.
Please focus on the Motivation section of each pattern first. You can skip a pattern if the problem presented in the Motivation section is not relevant to your situation.

After that please read
– this Frank Buschmann et al. (1996). Pattern-Oriented Software Architecture: A System Of Patterns. John Wiley & Sons Ltd book, and
– this Deepak Alur, Dan Malks and John Crupi (2003). Core J2EE Patterns: Best Practices And Design Strategies. Prentice Hall PTR book, and
– this Martin Fowler et al. (2002). Patterns Of Enterprise Application Architecture. Addison Wesley book.

After that please read
– this Meilir Page-Jones (1988). The Practical Guide to Structured Systems Design. Pearson Education book, and
– this Bertrand Meyer (1997). Object-Oriented Software Construction. Prentice Hall book, and
– this Grady Booch et al. (2007). Object-Oriented Analysis and Design with Applications. Pearson book, and
– this David Budgen (2003). Software Design. Pearson book and this David Budgen (2020). Software Design. CRC Press book
to learn how to design software systematically.

After that please read this Robert C. Martin (2017). Clean Architecture: A Craftsman’s Guide to Software Structure and Design. Pearson Education book to learn how to create a real world architecture for an enterprise system.

After that please read
– this Len Bass, Paul Clements and Rick Kazman (2012). Software Architecture in Practice. Addison-Wesley book to review software architecture aspects, and
– this Paul Clements et al. (2010). Documenting Software Architectures: Views and Beyond. Pearson book to learn how to document an architecture so that it can be used for communicated, built and maintained, and
– this Humberto Cervantes and Rick Kazman (2016). Designing Software Architectures: A Practical Approach. Addison-Wesley Professional book to learn how to create an architecture systematically, and
– this Nick Rozanski and Eoin Woods (2012). Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives. Addison-Wesley Professional book to learn how to apply theory to create an architecture systematically in real world.

After finishing the books please click Topic 13 – Software Project Management to continue.

Software Engineering Curriculum, Software Requirements

Topic 9 – Software Requirements

Leave a comment

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 a lower cost. In order to achieve this objective, it must fulfill the need of various users. To fulfill users’ needs you need to be able to identify their context, problems and desires, then propose software solutions for their issues.

Your software solutions must be built based on its users’ requirements. 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 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 scenarios that may suggest that you should come back to this topic is when you will have created an application but then unfortunately you find that no one wants to use it.

Alright! What should I do now?

Please read
– this Suzanne Robertson and James Robertson (2012). Mastering the Requirements Process. Addison Wesley Professional book, and
– this Karl Wiegers and Joy Beatty (2013). Software Requirements. Microsoft Press book.

After that please read this Joy Beatty and Anthony Chen (2012). Visual Models for Software Requirements. Microsoft Press book.

After that, please read this Alistair Cockburn (2001). Writing Effective Use Cases. Addison-Wesley book.

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

After that please read this Mike Cohn (2004). User Stories Applied: For Agile Software Development. Addison-Wesley Professional book.

After that please read this Jeff Patton and Peter Economy (2014). User Story Mapping. O’Reilly Media book.

After that please read this Dean Leffingwell (2011). Agile Software Requirements. Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional book.

After that please read this Project Management Institute (2015). Business Analysis for Practitioners – A Practice Guide. Project Management Institute book.

After finishing the books please click Topic 10 – Software Construction to continue.