In a recent Webinar on Writing Better Features I briefly mentioned slicing Features to create smaller Features, but didn’t have the time to do a deep dive on the topic of slicing Features. Whilst we at Ivar Jacobson Intl. have blogged about Preparing Features For PI Planning, which again mentions Feature Slicing it doesn’t go deep. As for the Framework, it leaves the preparation of Features open to interpretation without ever really explaining what makes a good feature and why.
So, this pair of blogs is a deep dive on Slicing Features. The previous blog looked at the Feature Slicing Patterns, this blog will look at Slicing Patterns In Practice.
Patterns In Practice
Regardless of which pattern is picked, the underlying principles that need to be adhered to are: Agile Principle #1 : Deliver working software frequently and often, and Agile Principle #7 : Working Software is the primary measure of progress. In practical terms we want to pick slices that allow us to demonstrate a working solution as quickly as possible. On large systems this might require applying the patterns recursively.
The following narrative is adapted from a real world scenario I encountered a few years ago and illustrates how the patterns are used recursively to get from something almost incomprehensibly big, to manageable pieces that start delivering value.
Ordering A Vehicle
I was working with one of the major automotive manufacturers and they were trying to standardise their ordering system onto one global ordering system rather than the 3 separate systems that had evolved independently in North America, Europe and Asia-Pacific.
Conceptually the process of ordering a car isn’t that difficult:
- Login, setup user privileges
- Configure the vehicle you’re after
- Locate from Inventory or Schedule A Manufacturing Slot
- Organise Finances
- Place The Order
- Register Vehicle With Local Government
- Deliver Vehicle
- Archive Everything for future analysis
However, once you start looking at the details the volume of work starts to become apparent…
Ordering a Vehicle is big. You just won’t believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think that finding a vehicle with the right colour is hard, but that’s just peanuts to actually Ordering a Vehicle.Apologies to Hitchhikers Guide To The Galaxy,
Douglas Adams
Choose a vehicle: There are approximately 20 models to choose from, each model has a number of different configurations options: engine size, exterior colour, interior fittings. Indeed, one model has so many configuration options that there are over a million possible permutations, the factory could be producing a vehicle every 2minutes for the next decade without repeating itself1. There are a lot of options to cover before you even get to the fancy real-time 3d visualisation of what your car will look like…
Register vehicle: Most governments like to have cars registered with them so that they can tax them and/or check that they are safe to be driven. There are approximately 195 countries in the world2, for some countries the volume of sales is so small that it’s not worth automating the process but about 50 of the countries have sufficient sales volume that it makes sense to build an interface directly to government systems and submit the registration details directly from the ordering system.
The other steps aren’t too dissimilar, whilst at their most abstract they are easy to comprehend, the effort lies in the detail of how it is achieved and there is a lot of effort involved in getting that detail right.
For now, each step gets a placeholder Feature that is dropped into the backlog. The Benefit Hypothesis and Acceptance Criteria are not detailed, these are merely placeholders in the backlog to remind us that slices are going to need to be peeled off of these features over time.
Features are tokens that trigger teams to create a potentially releasable set of changes to the system, they are not documentation of the system. The system is enshrined in the code3, the tests that verify the code does what it’s supposed to do, and the documentation that describes why the code and tests are the way they are. The documentation is important, it’s the strategy for how the system fits together, it needs to be evolved alongside, possibly just ahead, of the development work on the code. For now all it contains the 8 steps listed above, the detail about each will grow over time as and when the detail needs to be elaborated.
The Thinnest Thread Possible
The goal is to get the system working end-to-end as quickly as possible, this proves that it works and puts us in a position where we can incrementally build outwards, progressively improving the system.
KISS (Keep It Simple)
What is the simplest that can be done for each of the steps in order to allow that thinnest thread through the system?
Lots of people would start thinking about an MMR (a Minimum Marketable Release), but we need even less than that. The MMR for this system is the ability to configure, order, register and receive one model of car in one country; that is probably months worth of work, if not a year, of effort. The intent is to start with the thinnest thread to get the end-to-end running, then build up to the MMR.
| The MMR is negotiable |
|---|
|
Don’t treat the scope of the MMR as etched in stone, it should remain negotiable to honour SAFe Principle #3 : Assume Variability, Preserve Options. It is a target point, it provides the ART(s) with something to aim for but it will evolve. The scope could reduce if you realise that things aren’t as necessary as you thought they were back at the beginning. The scope could increase as you realise through demonstration and feedback that things are missing that the end-customers absolutely need. Changing the scope is a business decision, facilitated by the Product Management group. If the business increases the scope then the business needs to be aware that it will take longer to achieve the increased scope, therefore dates and deadlines need to be adjusted as well. |
Because we know that nothing is going to be released until there is the MMR, we can cheat a little during the early development. Usually the non-functional aspects of the system4 cannot be deferred, they need to be part of the Feature, but until we’re sufficiently far through the basic structure of the system that those non-functionals can be measured and assessed their implementation can be deferred. The non-functionals can’t be ignored completely; for the work that is being done, don’t do anything that would compromise the non-functionals in the future! Once a feature puts functionality in place, e.g. setting up User Privileges at Login, then every Feature beyond that point will need to factor in User Privileges if applicable.
The green outline represents the MMR, the red line the Thinnest Thread through the system end-to-end. What do the steps look like to reach the Thinnest Thread?
Login: Ignore for now, the login screen is a simple button that moves to the next screen. We can’t ignore user privileges for long, they’ll need to be in place for the MMR, but they’re not intrinsic to getting the thinnest thread running. Acceptance criteria for this feature: placeholder login screen with button to move to next screen.
Configure the vehicle you’re after: No user configuration; one model, known configuration, hardcoded. The configuration is guaranteed to work, so no need for error handling at this stage. Acceptance criteria for this feature: placeholder page with button to move to next screen, known configuration provided.
Locate from Inventory or Schedule A Manufacturing Slot: The order will be placed with the factory, all of the functionality about locating a vehicle within the existing inventory can be deferred.
Organise Finance: The customer is paying cash-on-delivery, i.e. we can ignore finance for now! This will be needed for the MMR because mass market car manufacturers make their money on the finance, not the manufacturing, but it’s not necessary for the thinnest thread. Acceptance criteria for this feature: placeholder page with button to move to next screen.
Place The Order: This step is important, this has to happen. The hardcoded configuration from earlier needs to be sent to the factory systems, the return response to be dumped as raw-text to screen or storage so that we can see how the factory has responded. Acceptance criteria for this feature: configuration sent to factory, response received and dumped for human analysis, no error handling or niceties.
Register Vehicle With Local Government: Pretend that this is happening manually, in other words: ignore for now. Acceptance criteria for this feature: placeholder page with button to move to next screen.
Deliver Vehicle: Collect from end of production line, in other words: ignore for now. Acceptance criteria for this feature: placeholder page with button to move to next screen.
Archive Everything for future analysis: There’s no archive to store things in yet and we’re not building it now, so ignore. Acceptance criteria for this feature: a placeholder function for the storage functionality.
Are these a single Feature that describes the thinnest thread, or are they separate Features for the steps in the thread? The former would be preferable since the value is self-contained within a single feature, but if that Feature is too big them it might be necessary to break it down by steps in the process. Steps in the process is not the ideal splitting choice because an individual step isn’t valuable in it’s own right, it’s only once the set of steps is available that the value is manifest.
| Visible Reminders or Hide What’s Not There |
|---|
|
In this particular example it was decided that missing functionality would be represented by placeholder screens to act as visible reminders that something needs to be there but is currently missing. Enough of the missing functionality would need to be created prior to the MMR being released that all of these screen would be resolved into something more substantial. However, there is a choice. Another option would have been to leave the screens out entirely. The advantage of this is that it would be easier to release at any time, even if the functionality isn’t complete, because the users wouldn’t know what they’re missing because they can’t see it, whereas with the placeholder screen they’ll know something is missing. For existing systems which have already been released, hiding the functionality until it’s ready, is preferable because it means the system could be released at any time, should the business deem it necessary. |
We’ve got a starting point, let’s get building…
You Can’t Just Start Building
…except this is a green-field site, there is nothing. Absolutely nothing.
Pick any business Feature you like from the identified set and the estimate on it is huge. This is true of all of them, regardless of whichever is chosen.
Why?
Whichever feature goes first has to bear the burden of the initial setup: build tools, environments, test areas, build pipeline. Because we don’t know which one is going to go first they all have to have that burden factored into their estimates, only once the first one has got the initial setup in place, and only once it has been done, can the remaining estimates be revised downwards now that the initial setup has been dealt with. The I of Bill Wake’s INVEST acronym is Independent, you have to estimate the items as if they were the only thing in the world, they have to do everything to get the change done.
Break Out Common Enablers
That initial setup is non-trivial, it is a sizeable chunk of those first slices. Separate out the preparatory work, the infrastructure to allow the teams to do the job of building the system. Stick a placeholder Feature for Continuous Delivery Pipeline (CDP) onto the backlog. Perhaps colour it red and tag it as an Enabler.
The whole continuous delivery pipeline is a big dream. There might even be bits that you haven’t dreamt you’d need yet, that will only emerge through building the system and all the tooling and infrastructure to support the building of the system. Treat the CDP Enabler Feature just like the other placeholder features, slice the valuable things we need to do now off, place the remainder back onto the backlog to remind us that there is more still to do.
Time to apply the splitting patterns recursively. The initial CDP; KISS (Keep It Simple) what’s the minimum needed to allow the thinnest strand to be built?
- Source code repository to store the code and tests
- Compilers & build script to build the code and tests
- An environment to run the built code in
- Agree an initial Definition-Of-Done
Do you need automation at this very early stage? Maybe not. Automated test environment? Again, maybe not. Do we want them? Yes! And probably sooner rather than later, but are they more important than getting that first thread running? No. If we can’t get that thinnest thread running, if the system can’t place an order, then automated build and test is irrelevant because the whole endeavour has stalled and is likely to be abandoned if the thinnest thread won’t run. Building them before the thinnest thread is potential waste. Is automated build and test more important than fattening up the thinnest thread? Yes. Don’t start building upon what’s already been built until you can prove that you haven’t broken what’s already been built. You could create features for automated build and test but defer elaborating the detail until their needed, you could make a note on the placeholder CDP Enabler Feature to remind you that these need to be done and/or a note in the documentation that describes the code, tests and tooling, that this still needs to be built and most importantly why it needs to be built, explain the value it provides.
The initial Definition-of-done will be simplistic, because the initial continuous delivery pipeline is simple. As the pipeline is progressively improved the Definition-of-done will be updated to cover the what the pipeline can now support.
It would also be sensible to have an over-arching architectural strategy before commencing development. The detail will emerge and be incorporated into the architectural strategy as it’s needed, but high-level design decisions such as where interfaces are, where data will be stored, probably needs to be understood upfront. Detail about the interfaces, exactly what data is being stored, that can be elaborated later. Again, what’s the smallest that can be done, enough that the thinnest thread is architecturally sound.
Any Colour You Like
The customers can have any colour they like, as long as it’s Black!
Is that going to make the customers happy?
| Probably not. |
Therefore it’s time to go back and improve the placeholder page for configuring the vehicle.
Consider Incrementally Sourcing Data
There are almost a hundred configurable parameters on the vehicle, from engine size and type, paint colour, through to interior fittings. Each of these can become a Feature in it’s own right to get allow the default configuration, the one that’s currently hardcoded in, to be manipulated and changed.
Which parameter do we start with?
Which is the most risky, the hardest to manipulate or present the options for? Do that, as it is helping to bring down the risk.
Does doing a parameter create functionality that will be reused by other parameters and thus make them easier or simpler to implement? Choose parameters that make the most other parameters easier.
KISS (Keep It Simple)
Recursion again. For each parameter we have to ask ourselves what’s the simplest that can be done. Paint colour:
- The simplest is a dropdown list containing the paint names.
- More complex would be a dropdown list containing the paint names and some form of visualisation of the colour.
- More complex again would be a dropdown list with accompanying visualisation of the vehicle so that the end-user can see what the vehicle will look like in their chosen colour.
Ultimately the big dream is the full 3d visualisation complete with shiny highlights that change as the vehicle is rotated in real-time. That’s what the end customers are going to want to see.
The immediate customers for the MMR however are sales staff within dealerships. Do they need a full 3d visualisation, no they can just turn around and look at the cars in their showroom! Currently they are used to a terminal program that uses an 80x25 character display and was upgraded from pure green-screen to CGA colour in the late 80’s. A modern dropdown list is still light years ahead of the existing systems, start with the simplest. Simple also allows the teams to test that the configurations are making it through to the factory a lot sooner than if they tried to develop the full visualisation.
In truth, the techies decided that adding a visualisation of the colour was trivial enough that they might as well do it as part of crafting the drop-down. Full real-time 3d visualisation was deferred until later and ended up being done by a team that specialised in 3d visualisation rather than the business applications teams.
Break Out Common Enablers
Whilst elaborating the Features for each of the configurable parameters, the question that kept coming up time and again was: Where does it fit on the screen?
It felt like some work was necessary to create a visual strategy for the page, roughly where controls would sit, which controls needed to be together, etc…
Therefore an Enabler Feature was created to determine the Visual Strategy for the configuration page, but time to invoke KISS again.
It is very easy to get lost into the pixel level detail when putting together a Visual Strategy, that’s not what’s needed up-front. Up-front it’s information about which controls are grouped together, perhaps a rough layout, the level of detail required is: drawn on the back of a napkin with a big fat marker pen! The pixel level detail can be negotiated as needed when implementing the individual components. The on-screen position isn’t going to materially affect estimation and planning, whereas the grouping will affect prioritisation and planning, you’ll probably want to prioritise and plan a group of controls as a block, even when the constituent pieces are developed individually.
The sheer volume of parameters was always going to take some time to get through. Initial estimates of a team getting through a parameter a week (remember that tests have to be developed, so a week to: discuss, implement tests, implement code, verify and submit, isn’t unreasonable), given the 4 teams available then the whole set of parameters would take two and half planning intervals, 25 weeks. In the end, commonality between components meant that later development was easier because it was repeating existing patterns that have been created by earlier parameters and the time came down to one and half planning intervals, which is still 4 months. The moral here is that a large volume of stuff can take a long time to get through; initial forecasts have to be based on a worst case scenario, once there is measurable proof that the team is getting quicker then, and only then, the forecasts can be wound in.
Politeness and Grace
To get to the thinnest thread as quickly as possible we ignored error handling and edge cases. This was a perfectly legitimate approach for proving that the thinnest thread works, that vehicles can be ordered, but it’s not something that can be allowed in the MMR. The MMR need to handle errors and edge cases with politeness and grace because it will be released to the users rather than ourselves.
KISS (Keep It Simple) – Incrementally layer up the complexity.
The first pass was the simplest, now it’s necessary to come back and create features to incrementally layer up the complexity.
- Error handling for when the Factory systems reject the given configuration.
- If the Ordering system can’t connect to the Factory system it needs to retry to connect or eventually fail gracefully with an error.
- Update the Development Documentation to describe the standards and patterns that future features should adhere to when connecting to external servers
The challenge is prioritising the error handling against new business functionality, the accusation of “no value” will be laid against the against the error handling.
Direct value, as in new functionality? No, but there is still value in the error handling. A graceful failure that informs the user of what’s happened is less likely to frustrate the user. Frustrated users will go elsewhere for the vehicles, so ultimately not implementing graceful error handling will have an impact on the bottom line of the accountancy spreadsheet.
This is where Chaos Monkey style testing is beneficial, knowing that servers will be inaccessible because the Monkey has pulled the connection forces the developers to code defensively and have a back-up plan for contacting alternate servers or failing gracefully. This will always result in more robust code than code that assumes the server is always present. The one thing that can be guaranteed is that if you assume that a server can never go down, then that server will be down, probably more often than not. All of this can be reflected in the Development Documentation and the initial, simple CDP tooling improved to test these sorts of scenarios.
That’s Not How We Do Things Around Here
One of the main requirements of the whole endeavour was to have a single standardised global system for ordering rather than the three separate systems that had evolved over the last 20 years. However, the reason that those separate systems had evolved is that the buying patterns of customers is different across the world, the single global system needs to accommodate those differing buying patterns.
Separate Business Variations
In North America the buying experience tends to be: the customer walks into a dealership, looks around the massive parking lot full of vehicles, picks the one that’s closest to what they want, maybe they have a test drive and if they are happy, pay for it and drive off in their new vehicle. Lots of space in North America, room for parking lots of vehicles waiting to be purchased.
In Europe the buying experience tends to be: the customer walks into a dealership, they test drive the model they are interested in, if they like it they sit down and decide what they actually want in their vehicle, once it has been paid for the order is sent to the factory, a few weeks later their exact vehicle is delivered.
The above patterns are generalisations, some North American customers do order a car that is manufactured exclusively for them and some European Customers do choose a car that dealerships already have sitting in their parking lots, but there tends to be less stock available ready to drive away in European dealerships.
Both patterns can be separated into their own Features.
The Manufacture Feature is already in progress, the thinnest thread has validated that an order could be placed at the factory. Now might be the point to improve upon the raw functionality, to provide estimates to the customer about how long the manufacturing will take so that they know when to expect their vehicle.
A Locate Feature that checks dealership stocks and finds the closest fit both in terms of vehicle configuration but also distance of dealership from the location that the customer has given. The customer can then be put in contact with the dealership to continue the purchase process. In itself the Locate Feature could be quite sizeable, applying the patterns recursively KISS (Keep it Simple) by doing exact matching, ignoring distance, and display a raw list of Dealerships, then come back with further features that improve the matching algorithm, prioritise Dealerships on distance and provide a more customer friendly display of Dealership details. On the other side Dealerships will need the ability to add and remove the stock that they hold as they buy and sell vehicles and potentially the ability to transfer stock between dealerships to facilitate the sale.
Access All Areas
Currently that is what the users have, complete unfettered access to the system. Probably best if we didn’t go live in that state because there are some things that the users currently have access to that they shouldn’t, that are reserved for the operational and administration staff.
Time to go back to the login page and start implementing the Login process and setting up user privileges.
Break Out Common Enablers
First thing is to get enough of the architecture for user privileges set up. What is the structure? How is the information going to be passed through the system? Example patterns to demonstrate how functionality should utilize the privileges mechanisms. A number of Enabler Features to get enough of the system in place?
KISS (Keep It Simple) – Incrementally layer up the complexity.
Does this need to be a full login system? No, not to begin with. Something to store the privileges for this session so that the functionality elsewhere in the system can check the privileges to see if the user has the right privilege to access this functionality. At this stage the login screen can be a simple drop-down to choose which user type you’d like to be, that’s enough to test that the privilege system is working.
Address Different User Groups Individually
There were a number of categories of user. Each category has different sets of privileges over what they can access and change within the system:
- Direct Customers – ability to configure a car through the webpages and purchase it
- Dealerships – ability to configure a car, eligible for incentives for selling certain categories of car, ability to see the collective orders and stock of the dealership and maintain or modify the orders and stock.
- Administrators – internal staff who add and remove dealership users from the system.
- Production Administrators – internal staff who need to add new vehicles or pre-defined configurations to the system.
- System Administrators – internal staff who need access to the internals of the system to check that it’s running correctly.
Which comes first the login screen to allow you to log in as an Administrator to allow you to set the user type to Administrator so that you can log in as an Administrator5… doesn’t matter because initially the earliest versions are reliant on hardcoded user types. The hardcoded users can instigate the real users and then be removed from the system.
Dealerships is the target group for MMR so that would be a good user group to start with; in order to create users the Administrator group will also be required. Production and Sys-Admin can be done manually to begin with, not ideal long term because there are more opportunities for mistakes with manual processes.
Dealerships User Group : Features to go back over the existing functionality, which is thankfully fairly minimal because there’s not much more than the thinnest thread, and add privilege checks around the functionality where appropriate. A Feature to update the documentation, including the definition of done, so that all future code developed utilises the privilege system and appropriate tests and reviews are carried out on that future code.
Administrators User Group : Features to add, remove, modify users, which in turn requires mechanisms for storing user information, notably passwords. Now that there are users, Features to log-in as a know user can be elaborated and one of the acceptance criteria there is that the temporary “choose your user-group type” is been removed from the login page.
Even here, KISS was being applied recursively, what’s the minimum that needs to be done now, what do we come back to later, either later in the journey to MMR or even after MMR. Anything later was added as notes to the placeholder features and/or the documentation to act a reminder of the discussions that were had and, more importantly, why is was decided that the functionality could be deferred.
A Manageable Start
The Minimum Marketable Release is targeting a small country in South America. The intent was to pick a small country so that the volume of sales is manageable by manual process if necessary, some of the smaller South America countries have sales volumes of around 100 vehicles per week, contrast that with the large North American countries which have a sales volume of a few hundred vehicles per-hour during daylight hours, impossible to manage manually if it goes wrong. South America is also being targeted because most of the potential countries are within an hours time-difference of Detroit so can be supported from head office. Some European countries would fit the sales volume criteria but they are several hours ahead of Detroit making support more challenging.
With a country in mind, what needs to be done to get the vehicles there?
Manufacturing is in North America, therefore delivery will be necessary. Features can be sliced off of the Delivery Placeholder to handle delivery to South America. Customs and import duties will be payable, Features to handle these for the initial country only.
As the Release expands to more countries more delivery options might be needed, certainly more customs, import and registration.
Making It Up As You Go
Isn’t this just making it up as you go? Isn’t it foolhardy to be doing that on such a big important system.
| Yes, and no. |
They are making it up as they go but it’s not a complete free for all, there are constraints.
The goal is clear, a single vehicle ordering system. There is inherent knowledge within the organisation of what that entails, the organisation has been selling vehicles for over a hundred years, they know what has to happen courtesy of their existing systems. The goal provides the intent.
There is a strategy. From a business perspective it’s start small before going global to manage the risk: What is needed for the first country? What can be deferred? Don’t do anything that would compromise the future rollout but equally don’t implement anything that isn’t needed now! From a technical perspective they now the high level flow, the customer journey, through the system, there is high level technical insight into what needs to be done where. Collectively the strategy is also providing intent that informs future decisions. It is the implementation decisions that are being work out as they are needed, this is being reflected in the Features and how the Features are broken down. Placeholder features for the grand steps in the strategy, the customer journey, slices being created as needed to elaborate and implement the detail, building up the system incrementally.
What makes this different from the old work breakdown structure is that you don’t define everything up front. Enough is defined, the goals and strategy, to start creating a working system. The working system provides feedback that can inform future Features and this feedback is received a lot earlier than if they had spent months or years trying to design a work breakdown up-front. To facilitate the progressive elaboration, the goal has to be clear from the start. If the goal isn’t clear then the first Features should be establishing that goal!
It is a journey, and just like a journey in the real world, you have a goal, a destination. Do you know exactly where you’re going to place your foot for each step of the journey? No, you’ll work that out as you go, but with each step you’re trying to move closer to the destination.
Challenges
Most engineers are actually quite good at taking a large problem and breaking it down into more manageable pieces, what they’re less good at is explaining how they’re doing the breakdown and getting it into writing so that others can understand what needs to be done. Do not underestimate the coaching required to extract that insight and capture it. Be aware of the psychology of the situation, the work is being captured not to hold the to it absolutely and punish them if it were wrong, but to make the steps visible to track progress, to ensure that the route they’re choosing aligns with the destination. If the route, the steps, change part way through then as long as they’re still heading towards the destination does it matter.
Some people will be worried that they won’t get everything they were hoping for if it’s built incrementally. The way to handle the situation is not to revert back to trying to define everything up front, but to set a clear goal and actively participate in the elaboration of the detail, steering the elaboration of the features, seeing the increments as the developed and using that feedback loop to drive what happens next.
There will be concerns that without a full Work Breakdown structure how will it be possible to determine how long it will take. Estimating problem solving is notoriously difficult, there are just too many uncertainties with problems to get precise estimates. It is better to chase value, get that thinnest thread working to start managing the risk and then iterate towards the Minimum Marketable Release, and be ruthless about what is essential for the Minimum Marketable Release. Once the release is out it should be generating value, ideally true business value, at worst the value is knowledge and insight to steer future development.
Conclusions
The narrative turned out a little longer than I first expected, but hopefully it illustrates that even with large endeavours, the global ordering system took several years, slicing the big chunks of functionality into smaller valuable pieces and recursively applying the patterns until the pieces are manageable and fit within the rules set for backlog items within Agile Teams or Agile Release Trains.
#1 30 cars / hour, 12 hours / day, 6 days / week, 50 weeks / year, 10 years produces 1,080,000 vehicles.
#2 Map Men : There are NOT 195 countries
#3 Substitute “designs and specification” for “code” if you are in the electro-mechanical space.
#4 Non-functionals are the emergent properties of the system: scale, throughput, responsiveness, security, etc… The non-functionals aren’t engineered directly, but as functionality is being created they need to considered and the emerging functional designs need to accommodate and adhere to the non-functional requirements.
#5 Chicken Or The Egg?