'''AntiPattern Name''':  ''RequirementsAsArchitecture''

'''Type''': ''Design''

'''Problem''': A project manager must get realized or a developer must realize a software without having an architecture competence available.

'''Context''': The project is driven by time constraints and probably TheCustomerIsSoMean.

'''Forces''': 
* The team in charge has no time to learn about architecture.
* There are no architecture competences available in the near area or it would be too hard to get them to work on the topic.
* The customer and/or line management don't want to see the problem.

'''Supposed Solution''': The project manager or developer takes the requirements as the architecture, so they interpret the customer's requirements as of they were written by IT architects.

'''Resulting Context''':
* You have a technical solution.
* The project manager and/or developer can confuse the customer by saying they implemented exactly what was asked in the requirements. It is often so esoteric for the customer that it will be difficult for him to realize he made the architecture.
* The problem is that it is very likely that the implemented solution will not work at all, or will work at an enormous price (for instance, a multiplication of the price of the project, important delays, functional incoherences, etc.).

'''Seductive forces''': This AntiPattern is very popular because a lot of project managers don't really understand the purpose of doing software architecture. Contractually, they prefer to interpret requirements in a way that leads the customer to endorse the responsibility of the architecture without him knowing exactly what all this is about.

'''Related AntiPattern''''''s''': ArchitectureMadeBySales

'''Applicable Positive Patterns''': ExplainSoftwareToTheCustomer, GetAnArchitectOnBoard

'''AntiPatternCategory''': ManagementAntiPattern, ArchitectureAntiPattern

'''Also Known As''': 

----
'''Examples in the Literature''':
----
'''Examples in Practice''':

Some service companies are working in this spirit. It is a very good way for them to confuse customers that don't understand IT. By using RequirementsAsArchitecture, the provider is guaranteed to obtain more services to sell in several phases of the project, in order to:
* Get the solution to finally work ;
* Complete the solution with all the necessary missing pieces (technical and functional components).
As all that is done upon a very bad architecture, all costs are multiplied by enormous factors. This can be a very profitable business model whereas it remains a very BadThing.
----
CategoryAntiPattern CategoryArchitectureAntiPattern