Behaviour Specifications Before Implementation
Behaviour Specifications are actual program specifications, and as such, it is common sense that the Behaviour Specifications should be written before attempting to do any coding of a software component.
If however, you are retrofitting behaviours for an existing software component, then you are in an interesting and potentially dangerous situation. The danger is that the team, when writing the specifications, could be too heavily influenced by the existing code and known internal implementation details, rather than writing Behaviour Specifications that better represent the core business requirements. Unless the team is at a mature level of writing Behaviour Specifications in common business language, I recommend that, at least for a large portion of the time allocated to write the specifications, pretend as if the code has not been written already. Either way, the team should keep referring back to the core business requirements, and perhaps only using the code to ensure that everything remains on track. Be careful and do not assume that the code is correct! Do not be surprised if you discover some defects!